From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon From danny.lessio at student.unife.it Tue Mar 1 16:44:38 2016 From: danny.lessio at student.unife.it (Danny Lessio) Date: Tue, 1 Mar 2016 22:44:38 +0100 Subject: [Rtk-users] Installation bash script for Linux users. Message-ID: Dear All, If can be helpful i have made a bash script that fully automates the compilation process of RTK for a Linux machine. You can find all the instructions here: https://github.com/dannylessio/auto-build-RTK Hope this can help someone. Thanks, Danny L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 2 01:37:37 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 2 Mar 2016 07:37:37 +0100 Subject: [Rtk-users] Installation bash script for Linux users. In-Reply-To: References: Message-ID: <56D68A31.7060502@creatis.insa-lyon.fr> Neat! I have added a link to your repo on the wiki: http://wiki.openrtk.org/index.php/RTK_wiki_help#Welcome_to_RTK Thanks a lot, Simon On 01/03/2016 22:44, Danny Lessio wrote: > Dear All, > > If can be helpful i have made a bash script that fully automates the > compilation process of RTK for a Linux machine. > > You can find all the instructions here: > https://github.com/dannylessio/auto-build-RTK > > Hope this can help someone. > > Thanks, > Danny L. > > > > > _______________________________________________ > 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 Wed Mar 2 06:59:16 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 2 Mar 2016 12:59:16 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: <56743FCB.3040102@creatis.insa-lyon.fr> References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hi Simon, I also got a question about how the weighting is performed. Before the question, first of all there may be an error in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I cannot see the reason for the factor 0.5 in the following code: //Last projection wraps the angle of the first one angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + 2*vnl_math::pi - curr->first ); If this is indeed wrong, then the max gap can be underestimated in the ParkerShortScanImageFilter, which you use for the 20 degree condition. Then here's the question: why does RTK eliminate the first and last projections before calculating the weights? The Parker weights are already all zeros for the first and the last projections involved in the calculation. If you rule out the first and the last projection in the data set in advance, you then have four projections with zeros and the effective scan angle is smaller then the actual short scan, which may lead to an insufficient data problem. Best regards, Chao 2015-12-18 18:18 GMT+01:00 Simon Rit : > Hi Shiras, > Sorry for the delayed answer, times are busy. The way RTK computes the > spanned arc is from the second projection angle to the before last > projection angle, i.e., in your case > 209.609216488925-11.6067737022482 > so it's a span of 199 degrees and your cone angle is indeed too large. > Like I said, this part of RTK is perfectible and there is no way to change > this but change the code. > However, the source of artefacts might be something else. On simulated > data, I tried: > rtkprojectshepploganphantom --like original_proj.mhd -g > geometry_parker_corr.xml -o proj.mha > rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml > and the result is not that bad. What do you think? Can you show us a > snapshot if sg's wrong in your opinion? > Simon > > > On 09/12/2015 11:01, Shiras Abdurahman wrote: > > Dear Simon, > > I am attaching the mhd files of projections. > > With regards, > Shiras > > On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > wrote: > >> Hi, >> The geometry files look ok to me. What is the projection information? If >> you're still getting the same message as before, I think it's because you >> don't have enough data. If you send the mhd file of the projections (just >> the mhd, not the raw data), I can try to test it on simulated data to let >> you know my feeling. >> Simon >> >> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >> shiraska at gmail.com> wrote: >> >>> Dear Simon, >>> >>> I tried this option and unfortunately it did not work. I added zero >>> projections and modified geometry files. However, I am getting same >>> artifacts in the volume. Voxel values changed a little bit that indicates >>> during backprojection it still considers extreme projections. I am also >>> getting an output message same as before. >>> >>> I am attaching geometry files. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> So calling AddProjection before and after the loop with an adequate >>>> gantry_angle should work. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Drear Simon, >>>>> >>>>> I generate the geometry with system geometry parameters and using >>>>> AddProjection method. >>>>> >>>>> Here is the code >>>>> >>>>> >>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>> proj_index++) >>>>> { >>>>> >>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>> } >>>>> >>>>> And then write to xml file. >>>>> >>>>> Shiras >>>>> >>>>> >>>>> >>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> Hi, >>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>> modify the geometry file. How do you generate the geometry? >>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>> were using: >>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>> then you'll have to replace it with >>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>> Don't forget to add dummy projection at the beginning and the end. If >>>>>> you use a more complex geometry, maybe SimpleRTK >>>>>> can be helpful >>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>> projections in the geometry and the projection stack. >>>>>> Simon >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Dear Simon, >>>>>>> >>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>> where the arc starts? >>>>>>> Do I need to modify geometry also? >>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>> helpful. >>>>>>> >>>>>>> With regards, >>>>>>> Shiras >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Dear Shiras, >>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>> when it's corrected. >>>>>>>> Simon >>>>>>>> >>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>> in command line or in my code? >>>>>>>> >>>>>>>> I really appreciate any help you can provide. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 jothybasu at gmail.com Fri Mar 4 00:13:35 2016 From: jothybasu at gmail.com (Jothybasu Selvaraj) Date: Fri, 4 Mar 2016 16:13:35 +1100 Subject: [Rtk-users] arg_info_rtkfdk Message-ID: ?Dear All I have just started to use RTK and its wonderful. Thanks for all the developers for their efforts in making this open source toolkit. i am planning to reconstruct a Varian CBCT?. I do not want to use gengetopt, rather I want to pass on the arguments to the classes from the values obtained from GUI. I get the error like this D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was not declared in this scope rtk::SetConstantImageSourceFromGgo(constantImageSource, args_info); How can I overcome this. Thanks very much in anticipation of your help. Regards Jothy ^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at uclouvain.be Fri Mar 4 03:48:55 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 4 Mar 2016 09:48:55 +0100 Subject: [Rtk-users] arg_info_rtkfdk In-Reply-To: References: Message-ID: <56D94BF7.7090806@uclouvain.be> Hi Jothy, The ConstantImageSource filter is a simple filter that just generates a uniform image (i.e. all pixels/voxels are filled with the same value). In rtkfdk, we generate an image filled with zeros and pass it in input to the fdk filter (it is absolutely necessary). This zero-filled image, however, must have the correct dimension, size, spacing, direction, etc... The line that throws an error is supposed to set those parameters on the ConstantImageSource filter, using the arguments provided on the command line, so that it generates an image with the right information. But you could use parameters taken from a GUI instead. Have a look at the source code of rtk::ConstantImageSource. The method "SetInformationFromImage" sets everything you need to set (it copies the parameters from another image, but you can just set the same parameters to what you get from the GUI). Hope it helps, Cyril On 03/04/2016 06:13 AM, Jothybasu Selvaraj wrote: > ?Dear All > > > I have just started to use RTK and its wonderful. Thanks for all the > developers for their efforts in making this open source toolkit. > > > > i am planning to reconstruct a Varian CBCT?. I do not want to use > gengetopt, rather I want to pass on the arguments to the classes from > the values obtained from GUI. > > I get the error like this > > D:\Projects\ReConnor\mainwindow.cpp:106: error: 'args_info_rtkfdk' was > not declared in this scope > rtk::SetConstantImageSourceFromGgo args_info_rtkfdk>(constantImageSource, args_info); > > How can I overcome this. > > Thanks very much in anticipation of your help. > > > Regards > > Jothy > ^ > > > _______________________________________________ > 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 Mar 6 06:57:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Sun, 6 Mar 2016 12:57:50 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: <56B9C430.80701@creatis.insa-lyon.fr> References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, We have to fix another date for the RTK training due to a conflicting meeting. If you are interested, please fill in the foodle so that we fix a date that suits everyone. If none of these dates works for you, please let me know and we'll try to extend the foodle. Please answer before Tuesday, we'll fix the date on Tuesday evening. Thanks for your cooperation and apologies for the mess, Simon On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit wrote: > Dear RTK users, > We will organize a new training > session on June 22 2016 in Lyon. Follow the instructions on the webpage > to register. The training is > for both users and developers. We are happy to answer any question that you > might have and we are looking forward to this new training session. > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solomoncztang at gmail.com Tue Mar 8 20:35:15 2016 From: solomoncztang at gmail.com (Solomon Tang) Date: Tue, 8 Mar 2016 17:35:15 -0800 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? Message-ID: Hi RTK users, I am trying to simulate motion artifacts in a phantom model. I have created a group of numberical phantoms, each one slightly shifted but with the same FOV, volume and origin. I am using the corresponding stack of projection files and an amsterdamshroud signal as an input to rtkfourdfdk However, I am getting an error that says :"Cannot account for too large detector displacements, a part of space must be covered by all projections. My phantoms are 2800,2800,20 with a spacing of 0.04 mm. My questions are how can I resolve this error, and is rtkfourdfdk even the function I want to use in the first place? Should I instead be trying to "compensate motion" on a static image? The end goal is to simulation motion artifacts that could be present in cardiac CTs. Thanks, Solomon -------------- next part -------------- An HTML attachment was scrubbed... URL: From didomenico at fe.infn.it Wed Mar 9 13:33:49 2016 From: didomenico at fe.infn.it (Giovanni Di Domenico) Date: Wed, 9 Mar 2016 19:33:49 +0100 Subject: [Rtk-users] compilation error Message-ID: Dear All, I am trying to compile the RTK toolkit v.1.2.0 but I receive the following error at the start of compilation process: -------------------------------------------------------------- .. CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): error: downloading ... status_code: 1 status_string: "Unsupported protocol" log: Protocol "https" not supported or disabled in libcurl Closing connection -1 make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 make: *** [all] Error 2 -------------------------------------------------------------------- The curl library is compiled with the https support. Could anyone help me about thi error? Thanks Giovanni Giovanni Di Domenico, Ph.D. Dipartimento di Fisica e Scienze della Terra Universita' degli Studi di Ferrara Polo Scientifico Tecnologico via Saragat 1 44122 Ferrara - ITALY e-mail: didomenico at fe.infn.it Phone: +39-0532-974223 FAX: +39-0532-974210 From cyril.mory at uclouvain.be Thu Mar 10 03:37:03 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Thu, 10 Mar 2016 09:37:03 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: <56E1322F.3080303@uclouvain.be> Hi Giovanni, This is not an RTK-related issue. Have you tried de-installing and re-installing (via your package manager) the libcurl library ? If you have compiled it yourself, can you make sure that you are using the one you have compiled, by checking your symbolic links (on OpenSuse it should be in /usr/lib64/, on other distributions I don't know). If you cannot find a solution, you should post your problem on a linux forum. As a (not recommended) workaround, if you disable the compilation of tests, you might have nothing to download (I'm not sure of this) and therefore avoid the libcurl problem. You can try it, but I do recommend you fix your libcurl problem. Hope it helps, Cyril On 03/09/2016 07:33 PM, Giovanni Di Domenico wrote: > Dear All, > > I am trying to compile the RTK toolkit v.1.2.0 but I receive the following > error at the start of compilation process: > -------------------------------------------------------------- > .. > CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): > error: downloading > ... > > status_code: 1 > status_string: "Unsupported protocol" > log: Protocol "https" not supported or disabled in libcurl > > Closing connection -1 > > > make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 > make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 > make: *** [all] Error 2 > -------------------------------------------------------------------- > > The curl library is compiled with the https support. > > Could anyone help me about thi error? > > Thanks > > Giovanni > > Giovanni Di Domenico, Ph.D. > Dipartimento di Fisica e Scienze della Terra > Universita' degli Studi di Ferrara > Polo Scientifico Tecnologico > via Saragat 1 > 44122 Ferrara - ITALY > e-mail: didomenico at fe.infn.it > Phone: +39-0532-974223 > FAX: +39-0532-974210 > > _______________________________________________ > 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 Mar 10 03:40:11 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 09:40:11 +0100 Subject: [Rtk-users] compilation error In-Reply-To: References: Message-ID: Sorry, I did not include the mailing list in my answer. See below. On Wed, Mar 9, 2016 at 9:27 PM, Simon Rit wrote: > Hi, > I presume you're trying to compile it with SimpleRTK ON on MacOS? If yes, > I had the same problem. blowekamp suggests a solution here > , that is, run cmake in > the following way: > cmake -DCMAKE_CXX_COMPILER:STRING=/usr/bin/clang++ > -DCMAKE_C_COMPILER:STRING=/usr/bin/clang SOURCE_DIR > where SOURCE_DIR is the path to your source directory. This worked for me. > Simon > > On Wed, Mar 9, 2016 at 7:33 PM, Giovanni Di Domenico < > didomenico at fe.infn.it> wrote: > >> Dear All, >> >> I am trying to compile the RTK toolkit v.1.2.0 but I receive the following >> error at the start of compilation process: >> -------------------------------------------------------------- >> .. >> CMake Error at PCRE-stamp/download-PCRE.cmake:27 (message): >> error: downloading >> ... >> >> status_code: 1 >> status_string: "Unsupported protocol" >> log: Protocol "https" not supported or disabled in libcurl >> >> Closing connection -1 >> >> >> make[2]: *** [PCRE-prefix/src/PCRE-stamp/PCRE-download] Error 1 >> make[1]: *** [CMakeFiles/PCRE.dir/all] Error 2 >> make: *** [all] Error 2 >> -------------------------------------------------------------------- >> >> The curl library is compiled with the https support. >> >> Could anyone help me about thi error? >> >> Thanks >> >> Giovanni >> >> Giovanni Di Domenico, Ph.D. >> Dipartimento di Fisica e Scienze della Terra >> Universita' degli Studi di Ferrara >> Polo Scientifico Tecnologico >> via Saragat 1 >> 44122 Ferrara - ITALY >> e-mail: didomenico at fe.infn.it >> Phone: +39-0532-974223 >> FAX: +39-0532-974210 >> >> _______________________________________________ >> 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 Mar 10 04:59:25 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 10:59:25 +0100 Subject: [Rtk-users] rtkfourdfdk simulate motion artifacts? In-Reply-To: References: Message-ID: Hi, Sorry but I don't understand what you're trying to do. The error message you get is because your geometry is not correct so you should check it. If you share the mhd header of the projection stack and the xml file for the RTK geometry, we can try to understand what's wrong. rtkfourdfdk reconstructs a 4D CBCT so it does not simulate motion artifacts. If you compensate motion on a static image, you also remove motion artifacts. If you want to simulate motion artifacts, I would do a plain static reconstruction, e.g., rtkfdk, from projections of a moving object. Simon On Wed, Mar 9, 2016 at 2:35 AM, Solomon Tang wrote: > Hi RTK users, > > I am trying to simulate motion artifacts in a phantom model. I have > created a group of numberical phantoms, each one slightly shifted but with > the same FOV, volume and origin. I am using the corresponding stack of > projection files and an amsterdamshroud signal as an input to rtkfourdfdk > > However, I am getting an error that says :"Cannot account for too large > detector displacements, a part of space must be covered by all projections. > My phantoms are 2800,2800,20 with a spacing of 0.04 mm. > > My questions are how can I resolve this error, and is rtkfourdfdk even the > function I want to use in the first place? Should I instead be trying to > "compensate motion" on a static image? The end goal is to simulation motion > artifacts that could be present in cardiac CTs. > > Thanks, > > Solomon > > _______________________________________________ > 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 Mar 10 05:02:53 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 10 Mar 2016 11:02:53 +0100 Subject: [Rtk-users] RTK training - June 22 2016 In-Reply-To: References: <56B9C430.80701@creatis.insa-lyon.fr> Message-ID: Dear all, The new date for the RTK training is Friday June 17. I'm looking forward to meeting you there, Simon On Sun, Mar 6, 2016 at 12:57 PM, Simon Rit wrote: > Dear all, > We have to fix another date for the RTK training due to a conflicting > meeting. If you are interested, please fill in the foodle > so that we > fix a date that suits everyone. If none of these dates works for you, > please let me know and we'll try to extend the foodle. > Please answer before Tuesday, we'll fix the date on Tuesday evening. > Thanks for your cooperation and apologies for the mess, > Simon > > On Tue, Feb 9, 2016 at 11:49 AM, Simon Rit > wrote: > >> Dear RTK users, >> We will organize a new training >> session on June 22 2016 in Lyon. Follow the instructions on the webpage >> to register. The training is >> for both users and developers. We are happy to answer any question that you >> might have and we are looking forward to this new training session. >> Simon >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Fri Mar 11 06:29:33 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 11 Mar 2016 12:29:33 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Hoi, I saw the factor 0.5 has been removed. Is there any concern about the second part of the question? Why to discard the first and last projections? Thanks. Regards, Chao 2016-03-02 12:59 GMT+01:00 Chao Wu : > Hi Simon, > > I also got a question about how the weighting is performed. > > Before the question, first of all there may be an error > in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I > cannot see the reason for the factor 0.5 in the following code: > //Last projection wraps the angle of the first one > angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + > 2*vnl_math::pi - curr->first ); > If this is indeed wrong, then the max gap can be underestimated in > the ParkerShortScanImageFilter, which you use for the 20 degree condition. > > Then here's the question: why does RTK eliminate the first and last > projections before calculating the weights? The Parker weights are already > all zeros for the first and the last projections involved in the > calculation. If you rule out the first and the last projection in the data > set in advance, you then have four projections with zeros and the effective > scan angle is smaller then the actual short scan, which may lead to an > insufficient data problem. > > Best regards, > Chao > > > > 2015-12-18 18:18 GMT+01:00 Simon Rit : > >> Hi Shiras, >> Sorry for the delayed answer, times are busy. The way RTK computes the >> spanned arc is from the second projection angle to the before last >> projection angle, i.e., in your case >> 209.609216488925-11.6067737022482 >> so it's a span of 199 degrees and your cone angle is indeed too large. >> Like I said, this part of RTK is perfectible and there is no way to change >> this but change the code. >> However, the source of artefacts might be something else. On simulated >> data, I tried: >> rtkprojectshepploganphantom --like original_proj.mhd -g >> geometry_parker_corr.xml -o proj.mha >> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >> and the result is not that bad. What do you think? Can you show us a >> snapshot if sg's wrong in your opinion? >> Simon >> >> >> On 09/12/2015 11:01, Shiras Abdurahman wrote: >> >> Dear Simon, >> >> I am attaching the mhd files of projections. >> >> With regards, >> Shiras >> >> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit > > wrote: >> >>> Hi, >>> The geometry files look ok to me. What is the projection information? If >>> you're still getting the same message as before, I think it's because you >>> don't have enough data. If you send the mhd file of the projections (just >>> the mhd, not the raw data), I can try to test it on simulated data to let >>> you know my feeling. >>> Simon >>> >>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>> shiraska at gmail.com> wrote: >>> >>>> Dear Simon, >>>> >>>> I tried this option and unfortunately it did not work. I added zero >>>> projections and modified geometry files. However, I am getting same >>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>> during backprojection it still considers extreme projections. I am also >>>> getting an output message same as before. >>>> >>>> I am attaching geometry files. >>>> >>>> With regards, >>>> Shiras >>>> >>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>> >>>>> So calling AddProjection before and after the loop with an adequate >>>>> gantry_angle should work. >>>>> Simon >>>>> >>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>> shiraska at gmail.com> wrote: >>>>> >>>>>> Drear Simon, >>>>>> >>>>>> I generate the geometry with system geometry parameters and using >>>>>> AddProjection method. >>>>>> >>>>>> Here is the code >>>>>> >>>>>> >>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>> proj_index++) >>>>>> { >>>>>> >>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>> } >>>>>> >>>>>> And then write to xml file. >>>>>> >>>>>> Shiras >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>> were using: >>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>> then you'll have to replace it with >>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>> can be helpful >>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>> projections in the geometry and the projection stack. >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>> shiraska at gmail.com> wrote: >>>>>>> >>>>>>>> Dear Simon, >>>>>>>> >>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>> where the arc starts? >>>>>>>> Do I need to modify geometry also? >>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>> helpful. >>>>>>>> >>>>>>>> With regards, >>>>>>>> Shiras >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Shiras, >>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>> when it's corrected. >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am trying to reconstruct a volume from projection data generated >>>>>>>>> with C-arm CT. There are 248 projections with an angular range of 199 >>>>>>>>> degree. Technically, parker weighting should run without any problems. >>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>> in command line or in my code? >>>>>>>>> >>>>>>>>> I really appreciate any help you can provide. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 Mar 11 12:24:32 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 11 Mar 2016 18:24:32 +0100 Subject: [Rtk-users] Parker weighting In-Reply-To: References: <56667F38.6040604@creatis.insa-lyon.fr> <56743FCB.3040102@creatis.insa-lyon.fr> Message-ID: Dear Chao, Sorry, I started working on your pertinent remarks (as always) but I did not finish accounting for the changes yet. Thanks for the bug report, I agree and changed it immediately, as you noticed. For Parker, I'm not sure why I did this but this is indeed wrong. Maybe I did not realize that the whole projection would be 0? Anyway, I fixed it but there are still 2 projections wrongly set to 0, we could also make use of them. I'll keep you posted when I have a solution, this is where it's a bit trickier... Thanks again, Simon On Fri, Mar 11, 2016 at 12:29 PM, Chao Wu wrote: > Hoi, > > I saw the factor 0.5 has been removed. Is there any concern about the > second part of the question? Why to discard the first and last projections? > Thanks. > > Regards, > Chao > > 2016-03-02 12:59 GMT+01:00 Chao Wu : > >> Hi Simon, >> >> I also got a question about how the weighting is performed. >> >> Before the question, first of all there may be an error >> in rtk::ThreeDCircularProjectionGeometry::GetAngularGapsWithNext(...). I >> cannot see the reason for the factor 0.5 in the following code: >> //Last projection wraps the angle of the first one >> angularGaps[curr->second] = 0.5 * ( sangles.begin()->first + >> 2*vnl_math::pi - curr->first ); >> If this is indeed wrong, then the max gap can be underestimated in >> the ParkerShortScanImageFilter, which you use for the 20 degree condition. >> >> Then here's the question: why does RTK eliminate the first and last >> projections before calculating the weights? The Parker weights are already >> all zeros for the first and the last projections involved in the >> calculation. If you rule out the first and the last projection in the data >> set in advance, you then have four projections with zeros and the effective >> scan angle is smaller then the actual short scan, which may lead to an >> insufficient data problem. >> >> Best regards, >> Chao >> >> >> >> 2015-12-18 18:18 GMT+01:00 Simon Rit : >> >>> Hi Shiras, >>> Sorry for the delayed answer, times are busy. The way RTK computes the >>> spanned arc is from the second projection angle to the before last >>> projection angle, i.e., in your case >>> 209.609216488925-11.6067737022482 >>> so it's a span of 199 degrees and your cone angle is indeed too large. >>> Like I said, this part of RTK is perfectible and there is no way to change >>> this but change the code. >>> However, the source of artefacts might be something else. On simulated >>> data, I tried: >>> rtkprojectshepploganphantom --like original_proj.mhd -g >>> geometry_parker_corr.xml -o proj.mha >>> rtkfdk -p . -r proj.mha -o fdk.mha -g geometry_parker_corr.xml >>> and the result is not that bad. What do you think? Can you show us a >>> snapshot if sg's wrong in your opinion? >>> Simon >>> >>> >>> On 09/12/2015 11:01, Shiras Abdurahman wrote: >>> >>> Dear Simon, >>> >>> I am attaching the mhd files of projections. >>> >>> With regards, >>> Shiras >>> >>> On Tue, Dec 8, 2015 at 6:17 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi, >>>> The geometry files look ok to me. What is the projection information? >>>> If you're still getting the same message as before, I think it's because >>>> you don't have enough data. If you send the mhd file of the projections >>>> (just the mhd, not the raw data), I can try to test it on simulated data to >>>> let you know my feeling. >>>> Simon >>>> >>>> On Tue, Dec 8, 2015 at 5:41 PM, Shiras Abdurahman < >>>> shiraska at gmail.com> wrote: >>>> >>>>> Dear Simon, >>>>> >>>>> I tried this option and unfortunately it did not work. I added zero >>>>> projections and modified geometry files. However, I am getting same >>>>> artifacts in the volume. Voxel values changed a little bit that indicates >>>>> during backprojection it still considers extreme projections. I am also >>>>> getting an output message same as before. >>>>> >>>>> I am attaching geometry files. >>>>> >>>>> With regards, >>>>> Shiras >>>>> >>>>> On Tue, Dec 8, 2015 at 10:15 AM, Simon Rit < >>>>> simon.rit at creatis.insa-lyon.fr> wrote: >>>>> >>>>>> So calling AddProjection before and after the loop with an adequate >>>>>> gantry_angle should work. >>>>>> Simon >>>>>> >>>>>> On Tue, Dec 8, 2015 at 9:52 AM, Shiras Abdurahman < >>>>>> shiraska at gmail.com> wrote: >>>>>> >>>>>>> Drear Simon, >>>>>>> >>>>>>> I generate the geometry with system geometry parameters and using >>>>>>> AddProjection method. >>>>>>> >>>>>>> Here is the code >>>>>>> >>>>>>> >>>>>>> rtk::ThreeDCircularProjectionGeometry::Pointer rtk_sys_geometry_; >>>>>>> rtk_sys_geometry_ = rtk::ThreeDCircularProjectionGeometry::New(); >>>>>>> for (uint16_t proj_index = 0; proj_index < num_projections_; >>>>>>> proj_index++) >>>>>>> { >>>>>>> >>>>>>> rtk_sys_geometry_->AddProjection(rtk_geom_params_.at(proj_index).sid_mm, >>>>>>> rtk_geom_params_.at(proj_index).sdd_mm, >>>>>>> rtk_geom_params_.at(proj_index).gantry_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).proj_offset_y_mm, >>>>>>> rtk_geom_params_.at(proj_index).out_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).in_plane_angle_deg, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_x_mm, >>>>>>> rtk_geom_params_.at(proj_index).src_offset_y_mm); >>>>>>> } >>>>>>> >>>>>>> And then write to xml file. >>>>>>> >>>>>>> Shiras >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Dec 8, 2015 at 9:23 AM, Simon Rit < >>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> rtkfdk.cxx just read the geometry from a file so the best is to >>>>>>>> modify the geometry file. How do you generate the geometry? >>>>>>>> For example, if you use rtksimulated geometry, let's say that you >>>>>>>> were using: >>>>>>>> rtksimulatedgeometry -n 200 -a 200 -o g.xml >>>>>>>> then you'll have to replace it with >>>>>>>> rtksimulatedgeometry -n 202 -a 202 -o g.xml -f -1 >>>>>>>> Don't forget to add dummy projection at the beginning and the end. >>>>>>>> If you use a more complex geometry, maybe SimpleRTK >>>>>>>> can be helpful >>>>>>>> (I'd use that) or you'd have to modify the cxx code to add these additional >>>>>>>> projections in the geometry and the projection stack. >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 8, 2015 at 8:51 AM, Shiras Abdurahman < >>>>>>>> shiraska at gmail.com> wrote: >>>>>>>> >>>>>>>>> Dear Simon, >>>>>>>>> >>>>>>>>> Thanks a lot for the reply. Can you please inform me how can I set >>>>>>>>> where the arc starts? >>>>>>>>> Do I need to modify geometry also? >>>>>>>>> If you can point the line of code rtkfdk.cxx, it will be really >>>>>>>>> helpful. >>>>>>>>> >>>>>>>>> With regards, >>>>>>>>> Shiras >>>>>>>>> >>>>>>>>> On Tue, Dec 8, 2015 at 7:56 AM, Simon Rit < >>>>>>>>> simon.rit at creatis.insa-lyon.fr> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Dear Shiras, >>>>>>>>>> Yes, for practical reasons the first and the last projections are >>>>>>>>>> set to 0 and the arc used in the Parker weighting starts between the first >>>>>>>>>> two projections and ends between the lasts two projections. There is a >>>>>>>>>> simple solution: add a projection at the beginning and the end of the arc, >>>>>>>>>> which can contain any pixel values but should be set where you want this >>>>>>>>>> arc to start. In the future, I think someone should once take the time to >>>>>>>>>> correct this but I haven't so far. I'll keep you posted on the mailing list >>>>>>>>>> when it's corrected. >>>>>>>>>> Simon >>>>>>>>>> >>>>>>>>>> On 07/12/2015 12:04, Shiras Abdurahman wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am trying to reconstruct a volume from projection data >>>>>>>>>> generated with C-arm CT. There are 248 projections with an angular range of >>>>>>>>>> 199 degree. Technically, parker weighting should run without any problems. >>>>>>>>>> However, I am getting an output message that "You do not have enough data >>>>>>>>>> for proper parker weighting". After parker weighting, the two extreme >>>>>>>>>> projections (projection number 1 and 248) were completely zero and thus >>>>>>>>>> reconstructed volume contained artifacts. When I increased the angular >>>>>>>>>> range, this problem did not happen. How can I solve this problem without >>>>>>>>>> increasing angular range? Is there any threshold constant that I can change >>>>>>>>>> in command line or in my code? >>>>>>>>>> >>>>>>>>>> I really appreciate any help you can provide. >>>>>>>>>> >>>>>>>>>> With regards, >>>>>>>>>> Shiras >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Rtk-users mailing listRtk-users at public.kitware.comhttp://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 C.Zoellner at physik.uni-muenchen.de Mon Mar 14 08:36:01 2016 From: C.Zoellner at physik.uni-muenchen.de (=?UTF-8?Q?Christoph_Z=c3=b6llner?=) Date: Mon, 14 Mar 2016 13:36:01 +0100 Subject: [Rtk-users] i0 error Message-ID: <56E6B031.9060608@physik.uni-muenchen.de> Dear all, I'd like to ask for your advice. While running the rtkfdk function with the --i0 option with CUDA on a linux machine, I'm getting the following error message: Regular expression matches 1 file(s)... ExceptionObject caught with reader->UpdateOutputInformation() in file /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 itk::ExceptionObject (0x29d20e0) Location: "unknown" File: /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx Line: 453 Description: itk::ERROR: Can not use I0 in LUTbasedVariableI0RawToAttenuationImageFilter with this input (not implemented) It says not implemented, but the i0-option is listed in the help menu. I'm using rtk 1.2.0. Regards, Christoph Zoellner From simon.rit at creatis.insa-lyon.fr Mon Mar 14 08:53:50 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 14 Mar 2016 13:53:50 +0100 Subject: [Rtk-users] i0 error In-Reply-To: <56E6B031.9060608@physik.uni-muenchen.de> References: <56E6B031.9060608@physik.uni-muenchen.de> Message-ID: Hi Christoph, The option is available but for a given type of projections only. The automated i0 detection only works with an unsigned short input, as you can see from the graph here in the ProjectionsReader documentation . With another type, e.g., float, that will not work. Regards, Simon On Mon, Mar 14, 2016 at 1:36 PM, Christoph Z?llner < C.Zoellner at physik.uni-muenchen.de> wrote: > Dear all, > > I'd like to ask for your advice. > > While running the rtkfdk function with the --i0 option with CUDA on a > linux machine, I'm getting the following error message: > > Regular expression matches 1 file(s)... > ExceptionObject caught with reader->UpdateOutputInformation() in file > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkGgoFunctions.h line 197 > > itk::ExceptionObject (0x29d20e0) > Location: "unknown" > File: > /scratch-local/rauscher/rtk_1.2.0/RTK-1.2.0/code/rtkProjectionsReader.txx > Line: 453 > Description: itk::ERROR: Can not use I0 in > LUTbasedVariableI0RawToAttenuationImageFilter with this input (not > implemented) > > > > It says not implemented, but the i0-option is listed in the help menu. > I'm using rtk 1.2.0. > > Regards, > > Christoph Zoellner > _______________________________________________ > 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 prekrasnaya1985 at gmail.com Tue Mar 15 02:19:59 2016 From: prekrasnaya1985 at gmail.com (Julia Semyakishkina) Date: Tue, 15 Mar 2016 12:19:59 +0600 Subject: [Rtk-users] artifacts on reconstruction Message-ID: Hello. I use RTK and another tomography packets/libraries for reconstruction and comparison results. RTK is one of the best for me, but with one model/sample i have strange artifacts, which doesn't appear in another packets. Here http://i.imgur.com/U9hqc6v.png is one projection. Here http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another packet. I am sure that i set geometry information correctly. Another models with the same tomograph, same geometry, same acquisition settings reconstuct fine and even better then in another packets. But exact reconstruction of the bug's foots caused to the artifacts. Even so, i think that is geometry problem. But i don't know how to solve it in RTK. I played with sid parameter in another packet and got very familiar artifacts, which appear with correct geometry in RTK. Just for test i played in the same way with RTK, i.e. change sid to wrong values and nothing changes except scale. Im a bit confused of this fact, i dont understand how sid\sdd doesn't make a sense in reconstruction, indeed when sid changes, beam angles which go through the model change, and from here projection shall be different. I can upload raw data with all meta info if needed. Any advice or direction where i should go to solve the problem would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Mar 15 02:37:42 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 15 Mar 2016 07:37:42 +0100 Subject: [Rtk-users] artifacts on reconstruction In-Reply-To: References: Message-ID: Dear Julia, Interesting, is this a crab? I agree with you, this is a geometry problem. My guess is that the projections are not adequately centered. If you use rtksimulatedgeometry to produce the geometry file for RTK, I would play with --proj_iso_x to correctly set the position of the projection of the rotation axis in the projections. Hopefully, this information is contained in your geometry information. I'm not surprised that --sid has mainly a magnification effect. I don't think sid/sdd is the main problem here. We can try to help if you can't figure it out but you'd have to send the data. Simon On Tue, Mar 15, 2016 at 7:19 AM, Julia Semyakishkina < prekrasnaya1985 at gmail.com> wrote: > Hello. I use RTK and another tomography packets/libraries for > reconstruction and comparison results. RTK is one of the best for me, but > with one model/sample i have strange artifacts, which doesn't appear in > another packets. > Here http://i.imgur.com/U9hqc6v.png is one projection. Here > http://i.imgur.com/MOlygHS.png is one slice reconstructed by RTK. Here > http://i.imgur.com/4a3jtLm.png is the same slice reconstructed by another > packet. > I am sure that i set geometry information correctly. Another models with > the same tomograph, same geometry, same acquisition settings reconstuct > fine and even better then in another packets. But exact reconstruction of > the bug's foots caused to the artifacts. > Even so, i think that is geometry problem. But i don't know how to solve > it in RTK. I played with sid parameter in another packet and got very > familiar artifacts, which appear with correct geometry in RTK. Just for > test i played in the same way with RTK, i.e. change sid to wrong values and > nothing changes except scale. Im a bit confused of this fact, i dont > understand how sid\sdd doesn't make a sense in reconstruction, indeed when > sid changes, beam angles which go through the model change, and from here > projection shall be different. > I can upload raw data with all meta info if needed. > Any advice or direction where i should go to solve the problem would be > appreciated. > > _______________________________________________ > 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 nabokajeleboka at gmail.com Wed Mar 16 08:11:09 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Wed, 16 Mar 2016 18:11:09 +0600 Subject: [Rtk-users] scanner development problems Message-ID: Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about my problems if anyone can help me.. I develop scanner. Reconstruction of parallelepiped or cube ( http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, without averaging and big rotation step. Yea, it seems that its mainly misalignments problems, so i calibrated sourceX, sourceY, detectorX, detectorY by the following method http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this information but without success. I also wrote a little program in this way for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset += searchStep) { sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); int r = system(cmd); sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); r = system(cmd); ... to search scanner alignment but also without success. I noticed interesting thing: when i specially offset detector horizontally to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on the center, reconstruct it, and here is phantom artifact, then i manually offset picture to the left on the tifs (from http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i work in this way, take scans when detector on the center, manually offset picture to the left and specify it by proj_iso_x to avoid phantom artifact, but its HUGE WORKAROUND =)) What do you think about it ? If its geometry issue, why real or virtual offset of detector cleans up the phantom artifact? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 16 08:45:20 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 16 Mar 2016 13:45:20 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Hi, I think it's a geometry problem. I don't have a solution for you but just a remark: how did you come up with the neworigin parameter? Changing this has a similar effect as changing the --proj_iso_x or "offseting" the projections. And it seems that the value you put (-18.137) makes no sense to me wrt the total width (800*0.0296=23.68). Typically, I center the projection which in your case would require as a new origin 799/-2*0.0296. I hope this helps, Simon On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov wrote: > Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about > my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or cube ( > http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( > http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, > without averaging and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, sourceY, detectorX, > detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got sourceX > = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this > information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; > sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; > sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < projXTo; projXOffset > += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 > --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f > --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r > [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 > --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 > --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset detector horizontally > to the right by 4.5mm from the center, and specify it by --proj_iso_x=4.5 > when generating geometry file, phantom disappears! ( > http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on > the center, reconstruct it, and here is phantom artifact, then i manually > offset picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and it > reconstructs without phantom with --proj_iso_x=4.5! So, for this moment i > work in this way, take scans when detector on the center, manually offset > picture to the left and specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, why real or virtual > offset of detector cleans up the phantom artifact? > > > _______________________________________________ > 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 jkeiriz at theobjects.com Thu Mar 17 09:22:39 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 09:22:39 -0400 Subject: [Rtk-users] Python Wrapping Message-ID: <000f01d18050$14306530$3c912f90$@com> Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 11:33:24 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 11:33:24 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <000f01d18050$14306530$3c912f90$@com> References: <000f01d18050$14306530$3c912f90$@com> Message-ID: <001b01d18062$581fbb80$085f3280$@com> Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Thu Mar 17 13:54:10 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 17 Mar 2016 18:54:10 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <001b01d18062$581fbb80$085f3280$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: > Hello again, > > I found out about the json wrapping files. I added the wrapping for all > the filters, but I haven?t noticed any effect from setting the filters !!! > > Any hints ? > > Regards, > > Johnson > > > > *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On > Behalf Of *Johnson Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > > > Hello, > > I am using the Python wrapped version of RTK. I have a question regarding > the wrapping: > > It seems that not all functionality is available, for example: for the *CudaFDKConeBeamReconstructionFilter, > *I was not able to set the cut frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > > > *[image: Description: cid:image002.jpg at 01CB5984.4EABACE0]* > > > *Johnson Keiriz, PhDSenior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Thu Mar 17 15:54:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Thu, 17 Mar 2016 15:54:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> Message-ID: <002701d18086$c174df10$445e9d30$@com> Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven?t noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Fri Mar 18 03:27:48 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 18 Mar 2016 08:27:48 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: Ok, sorry, I erroneously mixed the size of the reconstructed volume and the size of the projections. Then your calculation seems correct and I don't know where does your geometry problem come from. For sure, you don't have to shift the projections, --proj_iso_x does the same thing directly. Regards, Simon On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov wrote: > Dear Simon, as i understand --neworigin is origin for projections. my > projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > wrote: > >> Hi, >> I think it's a geometry problem. I don't have a solution for you but just >> a remark: how did you come up with the neworigin parameter? Changing this >> has a similar effect as changing the --proj_iso_x or "offseting" the >> projections. And it seems that the value you put (-18.137) makes no sense >> to me wrt the total width (800*0.0296=23.68). Typically, I center the >> projection which in your case would require as a new origin 799/-2*0.0296. >> I hope this helps, >> Simon >> >> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >> nabokajeleboka at gmail.com> wrote: >> >>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you about >>> my problems if anyone can help me.. >>> I develop scanner. Reconstruction of parallelepiped or cube ( >>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>> without averaging and big rotation step. Yea, it seems that its mainly >>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>> detectorY by the following method >>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>> information but without success. >>> >>> I also wrote a little program in this way >>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < sourceXTo; >>> sourceXOffset_ += searchStep) >>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < sourceYTo; >>> sourceYOffset_ += searchStep) >>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>> projXOffset += searchStep) >>> { >>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>> >>> int r = system(cmd); >>> >>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>> r = system(cmd); >>> ... >>> >>> to search scanner alignment but also without success. >>> >>> I noticed interesting thing: when i specially offset detector >>> horizontally to the right by 4.5mm from the center, and specify it by >>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>> the center, reconstruct it, and here is phantom artifact, then i manually >>> offset picture to the left on the tifs (from >>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>> i work in this way, take scans when detector on the center, manually offset >>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>> but its HUGE WORKAROUND =)) >>> >>> >>> What do you think about it ? If its geometry issue, why real or virtual >>> offset of detector cleans up the phantom artifact? >>> >>> >>> _______________________________________________ >>> 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 cyril.mory at uclouvain.be Fri Mar 18 04:12:30 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 09:12:30 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <002701d18086$c174df10$445e9d30$@com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> Message-ID: <56EBB86E.80409@uclouvain.be> Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: > > Hello, > > I did rebuild and now things are working. I tested reconstruction with > and without the filtering and there were differences. Though, I am not > sure that filtering have provided a better reconstruction. > > I want to experiment the iterative methods. Can you please confirm for > me which iterative method are fully implemented in CUDA: is it the > conjugate gradient or SART ? > > I have noticed that they are not wrapped at all, any guide on how to > introduce new filters? > > Once I have tested my wrapping, I will submit a github pull-request. > > Thanks, > > Johnson > > *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of > *Simon Rit > *Sent:* Thursday, March 17, 2016 1:54 PM > *To:* Johnson Keiriz > *Cc:* rtk-users at public.kitware.com > *Subject:* Re: [Rtk-users] Python Wrapping > > Hi, > > Good! Indeed, many things are not wrapped. There is a trick regarding > modifications of the wrappings. You need to either start from scratch > the compilation or delete the file > SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will > trigger a reconfiguration of the SimpleRTK and, hopefully, account for > your modifications. > > Don't hesitate to submit a github pull-request when you have something > working. > > Simon > > On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz > > wrote: > > Hello again, > > I found out about the json wrapping files. I added the wrapping for > all the filters, but I haven?t noticed any effect from setting the > filters !!! > > Any hints ? > > Regards, > > Johnson > > *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com > ] *On Behalf Of *Johnson > Keiriz > *Sent:* Thursday, March 17, 2016 9:23 AM > *To:* rtk-users at public.kitware.com > ; Simon Rit > *Subject:* [Rtk-users] Python Wrapping > > Hello, > > I am using the Python wrapped version of RTK. I have a question > regarding the wrapping: > > It seems that not all functionality is available, for example: for the > *CudaFDKConeBeamReconstructionFilter, *I was not able to set the cut > frequency of the any of the filters > > (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not > wrapped ? > > Thanks, > > Johnson > > *Description: cid:image002.jpg at 01CB5984.4EABACE0* > > > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 08:27:07 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 08:27:07 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <003f01d18111$7cf62bb0$76e28310$@com> Hi Cyril, Thanks for the valuable information, I will test and get back to you. Regards, Johnson From: Cyril Mory [mailto:cyril.mory at uclouvain.be] Sent: Friday, March 18, 2016 4:13 AM To: Johnson Keiriz; 'Simon Rit' Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi Johnson, Regarding the iterative methods: - In SART, you can use the CUDA forward and back projectors, but the rest of the calculation is performed on CPU. We do not use SART a lot, so we have not fully optimized it. - Conjugate gradient, on the other hand, is entirely performed on the GPU. Note that a regularized conjugate gradient reconstruction filter is also available (with total variation denoising, wavelets denoising, and positivity enforcement) I hope you will find what you need, Regards, Cyril On 03/17/2016 08:54 PM, Johnson Keiriz wrote: Hello, I did rebuild and now things are working. I tested reconstruction with and without the filtering and there were differences. Though, I am not sure that filtering have provided a better reconstruction. I want to experiment the iterative methods. Can you please confirm for me which iterative method are fully implemented in CUDA: is it the conjugate gradient or SART ? I have noticed that they are not wrapped at all, any guide on how to introduce new filters? Once I have tested my wrapping, I will submit a github pull-request. Thanks, Johnson From: simon.rit at gmail.com [mailto:simon.rit at gmail.com] On Behalf Of Simon Rit Sent: Thursday, March 17, 2016 1:54 PM To: Johnson Keiriz Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Python Wrapping Hi, Good! Indeed, many things are not wrapped. There is a trick regarding modifications of the wrappings. You need to either start from scratch the compilation or delete the file SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will trigger a reconfiguration of the SimpleRTK and, hopefully, account for your modifications. Don't hesitate to submit a github pull-request when you have something working. Simon On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz wrote: Hello again, I found out about the json wrapping files. I added the wrapping for all the filters, but I haven't noticed any effect from setting the filters !!! Any hints ? Regards, Johnson From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Johnson Keiriz Sent: Thursday, March 17, 2016 9:23 AM To: rtk-users at public.kitware.com; Simon Rit Subject: [Rtk-users] Python Wrapping Hello, I am using the Python wrapped version of RTK. I have a question regarding the wrapping: It seems that not all functionality is available, for example: for the CudaFDKConeBeamReconstructionFilter, I was not able to set the cut frequency of the any of the filters (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not wrapped ? Thanks, Johnson Description: cid:image002.jpg at 01CB5984.4EABACE0 Johnson Keiriz, PhD Senior Software Engineer 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 09:11:06 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 09:11:06 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBB86E.80409@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> Message-ID: <56EBFE6A.2070606@theobjects.com> Hello, Can you please confirm that the following classes are the ones used for the iterative reconstruction: 1 - SART: SARTConeBeamReconstructionFilter 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter Is there a 3D conjugate gradient? Are these the only classes for iterative reconstruction? Thanks, Johnson On 3/18/2016 4:12 AM, Cyril Mory wrote: > Hi Johnson, > > Regarding the iterative methods: > - In SART, you can use the CUDA forward and back projectors, but the > rest of the calculation is performed on CPU. We do not use SART a lot, > so we have not fully optimized it. > - Conjugate gradient, on the other hand, is entirely performed on the > GPU. Note that a regularized conjugate gradient reconstruction filter > is also available (with total variation denoising, wavelets denoising, > and positivity enforcement) > > I hope you will find what you need, > Regards, > Cyril > > On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >> >> Hello, >> >> I did rebuild and now things are working. I tested reconstruction >> with and without the filtering and there were differences. Though, I >> am not sure that filtering have provided a better reconstruction. >> >> I want to experiment the iterative methods. Can you please confirm >> for me which iterative method are fully implemented in CUDA: is it >> the conjugate gradient or SART ? >> >> I have noticed that they are not wrapped at all, any guide on how to >> introduce new filters? >> >> Once I have tested my wrapping, I will submit a github pull-request. >> >> Thanks, >> >> Johnson >> >> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf Of >> *Simon Rit >> *Sent:* Thursday, March 17, 2016 1:54 PM >> *To:* Johnson Keiriz >> *Cc:* rtk-users at public.kitware.com >> *Subject:* Re: [Rtk-users] Python Wrapping >> >> Hi, >> >> Good! Indeed, many things are not wrapped. There is a trick regarding >> modifications of the wrappings. You need to either start from scratch >> the compilation or delete the file >> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >> trigger a reconfiguration of the SimpleRTK and, hopefully, account >> for your modifications. >> >> Don't hesitate to submit a github pull-request when you have >> something working. >> >> Simon >> >> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >> > wrote: >> >> Hello again, >> >> I found out about the json wrapping files. I added the wrapping for >> all the filters, but I haven?t noticed any effect from setting the >> filters !!! >> >> Any hints ? >> >> Regards, >> >> Johnson >> >> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >> ] *On Behalf Of *Johnson >> Keiriz >> *Sent:* Thursday, March 17, 2016 9:23 AM >> *To:* rtk-users at public.kitware.com >> ; Simon Rit >> *Subject:* [Rtk-users] Python Wrapping >> >> Hello, >> >> I am using the Python wrapped version of RTK. I have a question >> regarding the wrapping: >> >> It seems that not all functionality is available, for example: for >> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >> cut frequency of the any of the filters >> >> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods not >> wrapped ? >> >> Thanks, >> >> Johnson >> >> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >> >> >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Fri Mar 18 09:31:33 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Fri, 18 Mar 2016 14:31:33 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EBFE6A.2070606@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> Message-ID: <56EC0335.50109@uclouvain.be> Hi again, You got the SART filter right. As for the conjugate gradient, the filter is actually ConjugateGradientConeBeamReconstructionFilter (for the 3D non-regularized reconstruction) and RegularizedConjugateGradientConeBeamReconstructionFilter (its regularized counterpart). The filter you found, FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D reconstruction (you need a cardiac or respiratory phase signal). Its regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. In addition to those, RTK also has ADMMTotalVariationConeBeamReconstructionFilter and ADMMWaveletsConeBeamReconstructionFilter, which implement the Alternating Direction Method of Multiplier algorithm. You can find a description of these algorithms in https://hal.inria.fr/tel-00985728/document Note that the SART filter has a m_NumberOfProjectionsPerSubset member. Setting it to 1 (default) gives you SART, setting it to n with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting it to n=TotalNumberOfProjections gives you SIRT. That's pretty much all there is in RTK at the moment. Cyril On 03/18/2016 02:11 PM, Johnson Keiriz wrote: > Hello, > Can you please confirm that the following classes are the ones used > for the iterative reconstruction: > 1 - SART: SARTConeBeamReconstructionFilter > 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter > > Is there a 3D conjugate gradient? > Are these the only classes for iterative reconstruction? > > Thanks, > Johnson > > On 3/18/2016 4:12 AM, Cyril Mory wrote: >> Hi Johnson, >> >> Regarding the iterative methods: >> - In SART, you can use the CUDA forward and back projectors, but the >> rest of the calculation is performed on CPU. We do not use SART a >> lot, so we have not fully optimized it. >> - Conjugate gradient, on the other hand, is entirely performed on the >> GPU. Note that a regularized conjugate gradient reconstruction filter >> is also available (with total variation denoising, wavelets >> denoising, and positivity enforcement) >> >> I hope you will find what you need, >> Regards, >> Cyril >> >> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>> >>> Hello, >>> >>> I did rebuild and now things are working. I tested reconstruction >>> with and without the filtering and there were differences. Though, I >>> am not sure that filtering have provided a better reconstruction. >>> >>> I want to experiment the iterative methods. Can you please confirm >>> for me which iterative method are fully implemented in CUDA: is it >>> the conjugate gradient or SART ? >>> >>> I have noticed that they are not wrapped at all, any guide on how to >>> introduce new filters? >>> >>> Once I have tested my wrapping, I will submit a github pull-request. >>> >>> Thanks, >>> >>> Johnson >>> >>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>> Of *Simon Rit >>> *Sent:* Thursday, March 17, 2016 1:54 PM >>> *To:* Johnson Keiriz >>> *Cc:* rtk-users at public.kitware.com >>> *Subject:* Re: [Rtk-users] Python Wrapping >>> >>> Hi, >>> >>> Good! Indeed, many things are not wrapped. There is a trick >>> regarding modifications of the wrappings. You need to either start >>> from scratch the compilation or delete the file >>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>> for your modifications. >>> >>> Don't hesitate to submit a github pull-request when you have >>> something working. >>> >>> Simon >>> >>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>> > wrote: >>> >>> Hello again, >>> >>> I found out about the json wrapping files. I added the wrapping for >>> all the filters, but I haven?t noticed any effect from setting the >>> filters !!! >>> >>> Any hints ? >>> >>> Regards, >>> >>> Johnson >>> >>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>> ] *On Behalf Of >>> *Johnson Keiriz >>> *Sent:* Thursday, March 17, 2016 9:23 AM >>> *To:* rtk-users at public.kitware.com >>> ; Simon Rit >>> *Subject:* [Rtk-users] Python Wrapping >>> >>> Hello, >>> >>> I am using the Python wrapped version of RTK. I have a question >>> regarding the wrapping: >>> >>> It seems that not all functionality is available, for example: for >>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set the >>> cut frequency of the any of the filters >>> >>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>> not wrapped ? >>> >>> Thanks, >>> >>> Johnson >>> >>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>> >>> >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 10:03:10 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 10:03:10 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC0A9E.5000106@theobjects.com> Perfect, thanks Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From naved.chaudhri at gmail.com Fri Mar 18 13:55:28 2016 From: naved.chaudhri at gmail.com (naved chaudhri) Date: Fri, 18 Mar 2016 18:55:28 +0100 Subject: [Rtk-users] how to assign itk::image object as projections Message-ID: Hi, I'm integrating RTK in an application that reads the raw projections from a dicom file. After reading dicom I have the data as itk::image object. At this point, I am facing difficulty in finding a way to assign the itk::image to rtk::ConstantImageSource or rtk::ProjectionsReader or not getting the way to rtk::FDKConeBeamReconstructionFilter for the reconstruction. All the application examples I went through were projections as stack based. Following are few lines I have written. // typedef itk::Image InImageType; InImageType::Pointer Img3DFloat = InImageType::New(); mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for reading and visualization) typename ConstantImageSourceType::Pointer iFilter = ConstantImageSourceType::New(); //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation error but Empty Reconstruction iFilter->SetInput(Img3DFloat ); //Compilation Error CbctGenerator.cpp:1338: error: no matching function for call to 'rtk::ConstantImageSource >::SetInput(itk::Image::Pointer&)' iFilter->SetInput(Img3DFloat ); // produces compilation error ^ // Thanks in advance for any hint. Bests, Naved -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeiriz at theobjects.com Fri Mar 18 14:16:50 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 14:16:50 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC0335.50109@uclouvain.be> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> Message-ID: <56EC4612.3000507@theobjects.com> Hello, I am trying to do the wrapping for the RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to wrap all the filters that it uses ? Is there any guiding document for the wrapping method? Regards, Johnson On 3/18/2016 9:31 AM, Cyril Mory wrote: > Hi again, > > You got the SART filter right. As for the conjugate gradient, the > filter is actually ConjugateGradientConeBeamReconstructionFilter (for > the 3D non-regularized reconstruction) and > RegularizedConjugateGradientConeBeamReconstructionFilter (its > regularized counterpart). > > The filter you found, > FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D > reconstruction (you need a cardiac or respiratory phase signal). Its > regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. > > In addition to those, RTK also has > ADMMTotalVariationConeBeamReconstructionFilter and > ADMMWaveletsConeBeamReconstructionFilter, which implement the > Alternating Direction Method of Multiplier algorithm. > > You can find a description of these algorithms in > https://hal.inria.fr/tel-00985728/document > > Note that the SART filter has a m_NumberOfProjectionsPerSubset member. > Setting it to 1 (default) gives you SART, setting it to n with 1 < n < > TotalNumberOfProjections gives you OS-SART, and setting it to > n=TotalNumberOfProjections gives you SIRT. > > That's pretty much all there is in RTK at the moment. > Cyril > > On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >> Hello, >> Can you please confirm that the following classes are the ones used >> for the iterative reconstruction: >> 1 - SART: SARTConeBeamReconstructionFilter >> 2- Conjugate gradient: FourDConjugateGradientConeBeamReconstructionFilter >> >> Is there a 3D conjugate gradient? >> Are these the only classes for iterative reconstruction? >> >> Thanks, >> Johnson >> >> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>> Hi Johnson, >>> >>> Regarding the iterative methods: >>> - In SART, you can use the CUDA forward and back projectors, but the >>> rest of the calculation is performed on CPU. We do not use SART a >>> lot, so we have not fully optimized it. >>> - Conjugate gradient, on the other hand, is entirely performed on >>> the GPU. Note that a regularized conjugate gradient reconstruction >>> filter is also available (with total variation denoising, wavelets >>> denoising, and positivity enforcement) >>> >>> I hope you will find what you need, >>> Regards, >>> Cyril >>> >>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>> >>>> Hello, >>>> >>>> I did rebuild and now things are working. I tested reconstruction >>>> with and without the filtering and there were differences. Though, >>>> I am not sure that filtering have provided a better reconstruction. >>>> >>>> I want to experiment the iterative methods. Can you please confirm >>>> for me which iterative method are fully implemented in CUDA: is it >>>> the conjugate gradient or SART ? >>>> >>>> I have noticed that they are not wrapped at all, any guide on how >>>> to introduce new filters? >>>> >>>> Once I have tested my wrapping, I will submit a github pull-request. >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>> Of *Simon Rit >>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>> *To:* Johnson Keiriz >>>> *Cc:* rtk-users at public.kitware.com >>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>> >>>> Hi, >>>> >>>> Good! Indeed, many things are not wrapped. There is a trick >>>> regarding modifications of the wrappings. You need to either start >>>> from scratch the compilation or delete the file >>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This will >>>> trigger a reconfiguration of the SimpleRTK and, hopefully, account >>>> for your modifications. >>>> >>>> Don't hesitate to submit a github pull-request when you have >>>> something working. >>>> >>>> Simon >>>> >>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>> > wrote: >>>> >>>> Hello again, >>>> >>>> I found out about the json wrapping files. I added the wrapping for >>>> all the filters, but I haven?t noticed any effect from setting the >>>> filters !!! >>>> >>>> Any hints ? >>>> >>>> Regards, >>>> >>>> Johnson >>>> >>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com >>>> ] *On Behalf Of >>>> *Johnson Keiriz >>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>> *To:* rtk-users at public.kitware.com >>>> ; Simon Rit >>>> *Subject:* [Rtk-users] Python Wrapping >>>> >>>> Hello, >>>> >>>> I am using the Python wrapped version of RTK. I have a question >>>> regarding the wrapping: >>>> >>>> It seems that not all functionality is available, for example: for >>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>> the cut frequency of the any of the filters >>>> >>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>> not wrapped ? >>>> >>>> Thanks, >>>> >>>> Johnson >>>> >>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>> >>>> >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:20:35 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:20:35 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC4612.3000507@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> Message-ID: <56EC5503.7070807@theobjects.com> Hello, I have tried to create a .json file for the *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the below errors while compiling. The json file contains: { "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", "template_code_filename" : "RTKImageFilter", "template_test_filename" : "ImageFilter", "number_of_inputs" : 2, "doc" : "", "output_image_type" : "TImageType", "pixel_types" : "RealPixelIDTypeList", "filter_type" : "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", "include_files" : [ "srtkThreeDCircularProjectionGeometry.h" ], "members" : [], "briefdescription" : "Implements regularized conjugate Gradient cone-beam reconstruction.", "detaileddescription" : "" } Error 1 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 2 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 3 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 4 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 5 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 6 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 7 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 8 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 9 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Error 10 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 SimpleRTK Error 11 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 SimpleRTK Error 12 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 SimpleRTK Error 13 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 SimpleRTK Error 14 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 SimpleRTK Error 15 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 1 SimpleRTK Error 16 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 1 SimpleRTK Error 17 error C2679: binary '=' : no operator found which takes a right-hand operand of type 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 129 1 SimpleRTK Error 18 error C2678: binary '*' : no operator found which takes a left-hand operand of type 'float' (or there is no acceptable conversion) [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK Thanks, Johnson On 3/18/2016 2:16 PM, Johnson Keiriz wrote: > Hello, > I am trying to do the wrapping for the > RegularizedConjugateGradientConeBeamReconstructionFilter, do I need to > wrap all the filters that it uses ? > Is there any guiding document for the wrapping method? > > Regards, > Johnson > > On 3/18/2016 9:31 AM, Cyril Mory wrote: >> Hi again, >> >> You got the SART filter right. As for the conjugate gradient, the >> filter is actually ConjugateGradientConeBeamReconstructionFilter (for >> the 3D non-regularized reconstruction) and >> RegularizedConjugateGradientConeBeamReconstructionFilter (its >> regularized counterpart). >> >> The filter you found, >> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >> reconstruction (you need a cardiac or respiratory phase signal). Its >> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >> >> In addition to those, RTK also has >> ADMMTotalVariationConeBeamReconstructionFilter and >> ADMMWaveletsConeBeamReconstructionFilter, which implement the >> Alternating Direction Method of Multiplier algorithm. >> >> You can find a description of these algorithms in >> https://hal.inria.fr/tel-00985728/document >> >> Note that the SART filter has a m_NumberOfProjectionsPerSubset >> member. Setting it to 1 (default) gives you SART, setting it to n >> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >> it to n=TotalNumberOfProjections gives you SIRT. >> >> That's pretty much all there is in RTK at the moment. >> Cyril >> >> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>> Hello, >>> Can you please confirm that the following classes are the ones used >>> for the iterative reconstruction: >>> 1 - SART: SARTConeBeamReconstructionFilter >>> 2- Conjugate gradient: >>> FourDConjugateGradientConeBeamReconstructionFilter >>> >>> Is there a 3D conjugate gradient? >>> Are these the only classes for iterative reconstruction? >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>> Hi Johnson, >>>> >>>> Regarding the iterative methods: >>>> - In SART, you can use the CUDA forward and back projectors, but >>>> the rest of the calculation is performed on CPU. We do not use SART >>>> a lot, so we have not fully optimized it. >>>> - Conjugate gradient, on the other hand, is entirely performed on >>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>> filter is also available (with total variation denoising, wavelets >>>> denoising, and positivity enforcement) >>>> >>>> I hope you will find what you need, >>>> Regards, >>>> Cyril >>>> >>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>> >>>>> Hello, >>>>> >>>>> I did rebuild and now things are working. I tested reconstruction >>>>> with and without the filtering and there were differences. Though, >>>>> I am not sure that filtering have provided a better reconstruction. >>>>> >>>>> I want to experiment the iterative methods. Can you please confirm >>>>> for me which iterative method are fully implemented in CUDA: is it >>>>> the conjugate gradient or SART ? >>>>> >>>>> I have noticed that they are not wrapped at all, any guide on how >>>>> to introduce new filters? >>>>> >>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On Behalf >>>>> Of *Simon Rit >>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>> *To:* Johnson Keiriz >>>>> *Cc:* rtk-users at public.kitware.com >>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>> >>>>> Hi, >>>>> >>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>> regarding modifications of the wrappings. You need to either start >>>>> from scratch the compilation or delete the file >>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>> account for your modifications. >>>>> >>>>> Don't hesitate to submit a github pull-request when you have >>>>> something working. >>>>> >>>>> Simon >>>>> >>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>> > wrote: >>>>> >>>>> Hello again, >>>>> >>>>> I found out about the json wrapping files. I added the wrapping >>>>> for all the filters, but I haven?t noticed any effect from setting >>>>> the filters !!! >>>>> >>>>> Any hints ? >>>>> >>>>> Regards, >>>>> >>>>> Johnson >>>>> >>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >>>>> Behalf Of *Johnson Keiriz >>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>> *To:* rtk-users at public.kitware.com >>>>> ; Simon Rit >>>>> *Subject:* [Rtk-users] Python Wrapping >>>>> >>>>> Hello, >>>>> >>>>> I am using the Python wrapped version of RTK. I have a question >>>>> regarding the wrapping: >>>>> >>>>> It seems that not all functionality is available, for example: for >>>>> the *CudaFDKConeBeamReconstructionFilter, *I was not able to set >>>>> the cut frequency of the any of the filters >>>>> >>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>> not wrapped ? >>>>> >>>>> Thanks, >>>>> >>>>> Johnson >>>>> >>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>> >>>>> >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> Rtk-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >> > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Fri Mar 18 15:23:09 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Fri, 18 Mar 2016 15:23:09 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC5503.7070807@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> Message-ID: <56EC559D.1000801@theobjects.com> To be specific: it gives an error at every CUDA filter !!! On 3/18/2016 3:20 PM, Johnson Keiriz wrote: > Hello, > I have tried to create a .json file for the > *RegularizedConjugateGradientConeBeamReconstructionFilter *and got the > below errors while compiling. > > The json file contains: > > { > "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", > "template_code_filename" : "RTKImageFilter", > "template_test_filename" : "ImageFilter", > "number_of_inputs" : 2, > "doc" : "", > "output_image_type" : "TImageType", > "pixel_types" : "RealPixelIDTypeList", > "filter_type" : > "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", > "include_files" : [ > "srtkThreeDCircularProjectionGeometry.h" > ], > "members" : [], > "briefdescription" : "Implements regularized conjugate Gradient > cone-beam reconstruction.", > "detaileddescription" : "" > } > > > Error 1 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 2 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 3 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 4 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 5 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 6 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 7 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 8 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 9 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > Error 10 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 > SimpleRTK > Error 11 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 > SimpleRTK > Error 12 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 > SimpleRTK > Error 13 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 > SimpleRTK > Error 14 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 > SimpleRTK > Error 15 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 42 > 1 SimpleRTK > Error 16 error C2679: binary '=' : no operator found which takes > a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' > (or there is no acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx 43 > 1 SimpleRTK > Error 17 error C2679: binary '=' : no operator found which takes > a right-hand operand of type > 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no > acceptable conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx > 129 1 SimpleRTK > Error 18 error C2678: binary '*' : no operator found which takes > a left-hand operand of type 'float' (or there is no acceptable > conversion) > [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] > c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK > > > Thanks, > Johnson > > On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >> Hello, >> I am trying to do the wrapping for the >> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >> to wrap all the filters that it uses ? >> Is there any guiding document for the wrapping method? >> >> Regards, >> Johnson >> >> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>> Hi again, >>> >>> You got the SART filter right. As for the conjugate gradient, the >>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>> (for the 3D non-regularized reconstruction) and >>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>> regularized counterpart). >>> >>> The filter you found, >>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>> reconstruction (you need a cardiac or respiratory phase signal). Its >>> regularized counterpart is FourDROOSTERConeBeamReconstructionFilter. >>> >>> In addition to those, RTK also has >>> ADMMTotalVariationConeBeamReconstructionFilter and >>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>> Alternating Direction Method of Multiplier algorithm. >>> >>> You can find a description of these algorithms in >>> https://hal.inria.fr/tel-00985728/document >>> >>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>> member. Setting it to 1 (default) gives you SART, setting it to n >>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and setting >>> it to n=TotalNumberOfProjections gives you SIRT. >>> >>> That's pretty much all there is in RTK at the moment. >>> Cyril >>> >>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>> Hello, >>>> Can you please confirm that the following classes are the ones used >>>> for the iterative reconstruction: >>>> 1 - SART: SARTConeBeamReconstructionFilter >>>> 2- Conjugate gradient: >>>> FourDConjugateGradientConeBeamReconstructionFilter >>>> >>>> Is there a 3D conjugate gradient? >>>> Are these the only classes for iterative reconstruction? >>>> >>>> Thanks, >>>> Johnson >>>> >>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>> Hi Johnson, >>>>> >>>>> Regarding the iterative methods: >>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>> the rest of the calculation is performed on CPU. We do not use >>>>> SART a lot, so we have not fully optimized it. >>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>> the GPU. Note that a regularized conjugate gradient reconstruction >>>>> filter is also available (with total variation denoising, wavelets >>>>> denoising, and positivity enforcement) >>>>> >>>>> I hope you will find what you need, >>>>> Regards, >>>>> Cyril >>>>> >>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I did rebuild and now things are working. I tested reconstruction >>>>>> with and without the filtering and there were differences. >>>>>> Though, I am not sure that filtering have provided a better >>>>>> reconstruction. >>>>>> >>>>>> I want to experiment the iterative methods. Can you please >>>>>> confirm for me which iterative method are fully implemented in >>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>> >>>>>> I have noticed that they are not wrapped at all, any guide on how >>>>>> to introduce new filters? >>>>>> >>>>>> Once I have tested my wrapping, I will submit a github pull-request. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>> Behalf Of *Simon Rit >>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>> *To:* Johnson Keiriz >>>>>> *Cc:* rtk-users at public.kitware.com >>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>> >>>>>> Hi, >>>>>> >>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>> regarding modifications of the wrappings. You need to either >>>>>> start from scratch the compilation or delete the file >>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>> account for your modifications. >>>>>> >>>>>> Don't hesitate to submit a github pull-request when you have >>>>>> something working. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>> > wrote: >>>>>> >>>>>> Hello again, >>>>>> >>>>>> I found out about the json wrapping files. I added the wrapping >>>>>> for all the filters, but I haven?t noticed any effect from >>>>>> setting the filters !!! >>>>>> >>>>>> Any hints ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>> *On Behalf Of *Johnson Keiriz >>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>> *To:* rtk-users at public.kitware.com >>>>>> ; Simon Rit >>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>> >>>>>> Hello, >>>>>> >>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>> regarding the wrapping: >>>>>> >>>>>> It seems that not all functionality is available, for example: >>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>> set the cut frequency of the any of the filters >>>>>> >>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the methods >>>>>> not wrapped ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Johnson >>>>>> >>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>> >>>>>> >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rtk-users mailing list >>>>>> Rtk-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>> >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From cyril.mory at uclouvain.be Mon Mar 21 04:40:37 2016 From: cyril.mory at uclouvain.be (Cyril Mory) Date: Mon, 21 Mar 2016 09:40:37 +0100 Subject: [Rtk-users] how to assign itk::image object as projections In-Reply-To: References: Message-ID: <56EFB385.5050608@uclouvain.be> Hi Naved, The ConstantImageSource filter generates an image with all pixels set to the same value (default value is 0), out of nothing. It does noes need an input. In fact, it cannot take an input. I do not know MITK, but mitk::CastToItkImage seems like a method that should return something. Something like a pointer to the image, cast as ITK image. You probably need to get this pointer and set it as input 1 of the FDK filter. Something like this, assuming there is something called ImageType in mitk : mitk::ImageType::Pointer castImagePointer = mitk::CastToItkImage(image, Img3DFloat); f->SetInput( 1, castImagePointer ); Note that circumventing the rtk::ProjectionsReader filter in such a way is usually a bad idea: before they can be back projected, projections usually need a lot of pre-processing, which is performed in the projections reader (like log-transform, LUT, parker weighting for short scans, offset-detector weighting, scatter correction, etc...). Hope it helps, Cyril On 03/18/2016 06:55 PM, naved chaudhri wrote: > Hi, > > I'm integrating RTK in an application that reads the raw projections > from a dicom file. After reading dicom I have the data as itk::image > object. At this point, I am facing difficulty in finding a way to > assign the itk::image to rtk::ConstantImageSource or > rtk::ProjectionsReader or not getting the way to > rtk::FDKConeBeamReconstructionFilter for the reconstruction. > > All the application examples I went through were projections as stack > based. > > Following are few lines I have written. > // > typedef itk::Image InImageType; > InImageType::Pointer Img3DFloat = InImageType::New(); > > mitk::CastToItkImage(image, Img3DFloat); //Works (I use MITK for > reading and visualization) > > typename ConstantImageSourceType::Pointer iFilter = > ConstantImageSourceType::New(); > //iFilter->SetInformationFromImage( Img3DFloat ); // No compilation > error but Empty Reconstruction > iFilter->SetInput(Img3DFloat ); //Compilation Error > > CbctGenerator.cpp:1338: error: no matching function for call to > 'rtk::ConstantImageSource > >::SetInput(itk::Image::Pointer&)' > iFilter->SetInput(Img3DFloat ); // produces compilation error > ^ > // > > Thanks in advance for any hint. > > Bests, > > Naved > > > > _______________________________________________ > 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 nabokajeleboka at gmail.com Mon Mar 21 10:25:14 2016 From: nabokajeleboka at gmail.com (Vasiliy Nabokov) Date: Mon, 21 Mar 2016 20:25:14 +0600 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: It worked now. The phantom artifact was caused by wrong rotate direction xD So, when i changed sort of regex result of my tifs from asc to desc phantom was disappeared! After scanner geometry calibration by article above, and my self algorithms i got not bad reconstruction by RTK for me. But there still remain two problems.. Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from scans like this http://i.imgur.com/qIYkvY7.png 1). Contrast. Structure reconstructs good, but hard to see. I receive 12 bit per pixel raw data from the detector, convert it to 16 bit just by (/4095.)*65535. What options i should play in RTK or while tifs generation at acquisition process in order to make structure more visible ? I tried different variants of voltage and current of tube, but on the picture is the best variant of contrast... 2). Also on the slice you can see circles that come from center. As i think its still geometry problems, i have to do calibration process better, isn't it ? On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit wrote: > Ok, sorry, I erroneously mixed the size of the reconstructed volume and > the size of the projections. Then your calculation seems correct and I > don't know where does your geometry problem come from. For sure, you don't > have to shift the projections, --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > wrote: > >> Dear Simon, as i understand --neworigin is origin for projections. my >> projection's width 2452 and spacing 0.0148, so 2451/-2*0.0148=-18.137 >> >> On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi, >>> I think it's a geometry problem. I don't have a solution for you but >>> just a remark: how did you come up with the neworigin parameter? Changing >>> this has a similar effect as changing the --proj_iso_x or "offseting" the >>> projections. And it seems that the value you put (-18.137) makes no sense >>> to me wrt the total width (800*0.0296=23.68). Typically, I center the >>> projection which in your case would require as a new origin 799/-2*0.0296. >>> I hope this helps, >>> Simon >>> >>> On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov < >>> nabokajeleboka at gmail.com> wrote: >>> >>>> Hi dear RTK users. Sorry, its offtop post... i just wanna tell you >>>> about my problems if anyone can help me.. >>>> I develop scanner. Reconstruction of parallelepiped or cube ( >>>> http://i.imgur.com/9YHyfWH.jpg) caused to phantom artifact ( >>>> http://i.imgur.com/yyI184j.png). Don't look at noise, its test scan, >>>> without averaging and big rotation step. Yea, it seems that its mainly >>>> misalignments problems, so i calibrated sourceX, sourceY, detectorX, >>>> detectorY by the following method >>>> http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, got >>>> sourceX = -215 mkm, sourceY = 650 mkm, detectorX = 50mkm. i specify this >>>> information but without success. >>>> >>>> I also wrote a little program in this way >>>> for (float sourceXOffset_ = sourceXFrom; sourceXOffset_ < >>>> sourceXTo; sourceXOffset_ += searchStep) >>>> for (float sourceYOffset_ = sourceYFrom; sourceYOffset_ < >>>> sourceYTo; sourceYOffset_ += searchStep) >>>> for (float projXOffset = projXFrom; projXOffset < projXTo; >>>> projXOffset += searchStep) >>>> { >>>> sprintf(cmd, "./rtksimulatedgeometry -o geometry.xml --n 90 >>>> --arc=360 --sdd=232.241 --sid=170 --source_x=%.6f --source_y=%.6f >>>> --proj_iso_x=%.6f", sourceXOffset_, sourceYOffset_, projXOffset); >>>> >>>> int r = system(cmd); >>>> >>>> sprintf(cmd, "./rtkfdk --hardware=cuda -p /home/fee/Public/ -r >>>> [0-9]+.tif$ -o dump/out.mha -g geometry.xml --verbose --dimension 800,1,800 >>>> --spacing 0.0296 --newspacing 0.0148 --neworigin -18.137,-12.128,0 >>>> --subsetsize=1 -l --origin -11.8252,-3.55,-11.8252"); >>>> r = system(cmd); >>>> ... >>>> >>>> to search scanner alignment but also without success. >>>> >>>> I noticed interesting thing: when i specially offset detector >>>> horizontally to the right by 4.5mm from the center, and specify it by >>>> --proj_iso_x=4.5 when generating geometry file, phantom disappears! ( >>>> http://i.imgur.com/OOsPsfL.png) I even take scans when the detector on >>>> the center, reconstruct it, and here is phantom artifact, then i manually >>>> offset picture to the left on the tifs (from >>>> http://i.imgur.com/FGxCJUo.png to http://i.imgur.com/brbp5sd.png), and >>>> it reconstructs without phantom with --proj_iso_x=4.5! So, for this moment >>>> i work in this way, take scans when detector on the center, manually offset >>>> picture to the left and specify it by proj_iso_x to avoid phantom artifact, >>>> but its HUGE WORKAROUND =)) >>>> >>>> >>>> What do you think about it ? If its geometry issue, why real or virtual >>>> offset of detector cleans up the phantom artifact? >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 21 11:46:55 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 21 Mar 2016 16:46:55 +0100 Subject: [Rtk-users] scanner development problems In-Reply-To: References: Message-ID: <56F0176F.2090702@creatis.insa-lyon.fr> Hi, It seems to me that your window/level is not adjusted for visualization which is not an RTK problem. What software do you use for visualization? Try to find out how to adjust the contrast on it. I can't see from the image you sent if there is a problem and what it is. Regarding rings, I'm not sure it comes from the calibration, these are probably due to defects in your projections. A simple solution is to pass a median filter, e.g., with rtkmedian. Simon On 21/03/2016 15:25, Vasiliy Nabokov wrote: > It worked now. The phantom artifact was caused by wrong rotate > direction xD So, when i changed sort of regex result of my tifs from > asc to desc phantom was disappeared! > After scanner geometry calibration by article above, and my self > algorithms i got not bad reconstruction by RTK for me. But there still > remain two problems.. > Here is one slice http://i.imgur.com/oVHCodb.png reconstructed from > scans like this http://i.imgur.com/qIYkvY7.png > 1). Contrast. Structure reconstructs good, but hard to see. I receive > 12 bit per pixel raw data from the detector, convert it to 16 bit just > by (/4095.)*65535. What options i should play in RTK or while tifs > generation at acquisition process in order to make structure more > visible ? I tried different variants of voltage and current of tube, > but on the picture is the best variant of contrast... > 2). Also on the slice you can see circles that come from center. As i > think its still geometry problems, i have to do calibration process > better, isn't it ? > > > > On Fri, Mar 18, 2016 at 1:27 PM, Simon Rit > > wrote: > > Ok, sorry, I erroneously mixed the size of the reconstructed > volume and the size of the projections. Then your calculation > seems correct and I don't know where does your geometry problem > come from. For sure, you don't have to shift the projections, > --proj_iso_x does the same thing directly. > Regards, > Simon > > On Thu, Mar 17, 2016 at 4:23 AM, Vasiliy Nabokov > > wrote: > > Dear Simon, as i understand --neworigin is origin for > projections. my projection's width 2452 and spacing 0.0148, so > 2451/-2*0.0148=-18.137 > > On Wed, Mar 16, 2016 at 6:45 PM, Simon Rit > > wrote: > > Hi, > I think it's a geometry problem. I don't have a solution > for you but just a remark: how did you come up with the > neworigin parameter? Changing this has a similar effect as > changing the --proj_iso_x or "offseting" the projections. > And it seems that the value you put (-18.137) makes no > sense to me wrt the total width (800*0.0296=23.68). > Typically, I center the projection which in your case > would require as a new origin 799/-2*0.0296. > I hope this helps, > Simon > > On Wed, Mar 16, 2016 at 1:11 PM, Vasiliy Nabokov > > wrote: > > Hi dear RTK users. Sorry, its offtop post... i just > wanna tell you about my problems if anyone can help me.. > I develop scanner. Reconstruction of parallelepiped or > cube (http://i.imgur.com/9YHyfWH.jpg) caused to > phantom artifact (http://i.imgur.com/yyI184j.png). > Don't look at noise, its test scan, without averaging > and big rotation step. Yea, it seems that its mainly > misalignments problems, so i calibrated sourceX, > sourceY, detectorX, detectorY by the following method > http://www1.jinr.ru/Pepan_letters/panl_2015_5/10_gongad.pdf, > got sourceX = -215 mkm, sourceY = 650 mkm, detectorX = > 50mkm. i specify this information but without success. > > I also wrote a little program in this way > for (float sourceXOffset_ = sourceXFrom; > sourceXOffset_ < sourceXTo; sourceXOffset_ += searchStep) > for (float sourceYOffset_ = sourceYFrom; > sourceYOffset_ < sourceYTo; sourceYOffset_ += searchStep) > for (float projXOffset = projXFrom; projXOffset < > projXTo; projXOffset += searchStep) > { > sprintf(cmd, "./rtksimulatedgeometry -o > geometry.xml --n 90 --arc=360 --sdd=232.241 --sid=170 > --source_x=%.6f --source_y=%.6f --proj_iso_x=%.6f", > sourceXOffset_, sourceYOffset_, projXOffset); > > int r = system(cmd); > > sprintf(cmd, "./rtkfdk --hardware=cuda -p > /home/fee/Public/ -r [0-9]+.tif$ -o dump/out.mha -g > geometry.xml --verbose --dimension 800,1,800 --spacing > 0.0296 --newspacing 0.0148 --neworigin > -18.137,-12.128,0 --subsetsize=1 -l --origin > -11.8252,-3.55,-11.8252"); > r = system(cmd); > ... > > to search scanner alignment but also without success. > > I noticed interesting thing: when i specially offset > detector horizontally to the right by 4.5mm from the > center, and specify it by --proj_iso_x=4.5 when > generating geometry file, phantom disappears! > (http://i.imgur.com/OOsPsfL.png) I even take scans > when the detector on the center, reconstruct it, and > here is phantom artifact, then i manually offset > picture to the left on the tifs (from > http://i.imgur.com/FGxCJUo.png to > http://i.imgur.com/brbp5sd.png), and it reconstructs > without phantom with --proj_iso_x=4.5! So, for this > moment i work in this way, take scans when detector on > the center, manually offset picture to the left and > specify it by proj_iso_x to avoid phantom artifact, > but its HUGE WORKAROUND =)) > > > What do you think about it ? If its geometry issue, > why real or virtual offset of detector cleans up the > phantom artifact? > > > _______________________________________________ > 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 Tue Mar 22 02:56:16 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 22 Mar 2016 07:56:16 +0100 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56EC559D.1000801@theobjects.com> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> Message-ID: <56F0EC90.2060107@creatis.insa-lyon.fr> Hi, We have had the same problem with ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed 2 days ago. Maybe have a look at this file to see if you can find some useful inspiration? Otherwise I'll try to fix your file later. Simon On 18/03/2016 20:23, Johnson Keiriz wrote: > To be specific: it gives an error at every CUDA filter !!! > > On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >> Hello, >> I have tried to create a .json file for the >> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >> the below errors while compiling. >> >> The json file contains: >> >> { >> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >> "template_code_filename" : "RTKImageFilter", >> "template_test_filename" : "ImageFilter", >> "number_of_inputs" : 2, >> "doc" : "", >> "output_image_type" : "TImageType", >> "pixel_types" : "RealPixelIDTypeList", >> "filter_type" : >> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >> "include_files" : [ >> "srtkThreeDCircularProjectionGeometry.h" >> ], >> "members" : [], >> "briefdescription" : "Implements regularized conjugate Gradient >> cone-beam reconstruction.", >> "detaileddescription" : "" >> } >> >> >> Error 1 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 2 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 3 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 4 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 5 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaLaplacianImageFilter::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 6 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 7 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type 'rtk::CudaConstantVolumeSource::Pointer' >> (or there is no acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 8 error C2679: binary '=' : no operator found which takes >> a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 9 error C2678: binary '*' : no operator found which takes >> a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> Error 10 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >> SimpleRTK >> Error 11 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >> SimpleRTK >> Error 12 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 1 >> SimpleRTK >> Error 13 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 1 >> SimpleRTK >> Error 14 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 1 >> SimpleRTK >> Error 15 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 42 1 SimpleRTK >> Error 16 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 43 1 SimpleRTK >> Error 17 error C2679: binary '=' : no operator found which >> takes a right-hand operand of type >> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >> acceptable conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >> 129 1 SimpleRTK >> Error 18 error C2678: binary '*' : no operator found which >> takes a left-hand operand of type 'float' (or there is no acceptable >> conversion) >> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >> >> >> Thanks, >> Johnson >> >> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>> Hello, >>> I am trying to do the wrapping for the >>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>> to wrap all the filters that it uses ? >>> Is there any guiding document for the wrapping method? >>> >>> Regards, >>> Johnson >>> >>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>> Hi again, >>>> >>>> You got the SART filter right. As for the conjugate gradient, the >>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>> (for the 3D non-regularized reconstruction) and >>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>> regularized counterpart). >>>> >>>> The filter you found, >>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>> reconstruction (you need a cardiac or respiratory phase signal). >>>> Its regularized counterpart is >>>> FourDROOSTERConeBeamReconstructionFilter. >>>> >>>> In addition to those, RTK also has >>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>> Alternating Direction Method of Multiplier algorithm. >>>> >>>> You can find a description of these algorithms in >>>> https://hal.inria.fr/tel-00985728/document >>>> >>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>> >>>> That's pretty much all there is in RTK at the moment. >>>> Cyril >>>> >>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>> Hello, >>>>> Can you please confirm that the following classes are the ones >>>>> used for the iterative reconstruction: >>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>> 2- Conjugate gradient: >>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>> >>>>> Is there a 3D conjugate gradient? >>>>> Are these the only classes for iterative reconstruction? >>>>> >>>>> Thanks, >>>>> Johnson >>>>> >>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>> Hi Johnson, >>>>>> >>>>>> Regarding the iterative methods: >>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>> SART a lot, so we have not fully optimized it. >>>>>> - Conjugate gradient, on the other hand, is entirely performed on >>>>>> the GPU. Note that a regularized conjugate gradient >>>>>> reconstruction filter is also available (with total variation >>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>> >>>>>> I hope you will find what you need, >>>>>> Regards, >>>>>> Cyril >>>>>> >>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I did rebuild and now things are working. I tested >>>>>>> reconstruction with and without the filtering and there were >>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>> a better reconstruction. >>>>>>> >>>>>>> I want to experiment the iterative methods. Can you please >>>>>>> confirm for me which iterative method are fully implemented in >>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>> >>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>> how to introduce new filters? >>>>>>> >>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>> pull-request. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>> Behalf Of *Simon Rit >>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>> *To:* Johnson Keiriz >>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>> regarding modifications of the wrappings. You need to either >>>>>>> start from scratch the compilation or delete the file >>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>> account for your modifications. >>>>>>> >>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>> something working. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>> > wrote: >>>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>> setting the filters !!! >>>>>>> >>>>>>> Any hints ? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>> *To:* rtk-users at public.kitware.com >>>>>>> ; Simon Rit >>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>> regarding the wrapping: >>>>>>> >>>>>>> It seems that not all functionality is available, for example: >>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able to >>>>>>> set the cut frequency of the any of the filters >>>>>>> >>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>> methods not wrapped ? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Johnson >>>>>>> >>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Johnson Keiriz, PhD >>>>>>> Senior Software Engineer* >>>>>>> >>>>>>> 760 St-Paul W, #101 >>>>>>> Montreal, QC >>>>>>> Canada H3C 1M4 >>>>>>> tel: (514) 843-3861 >>>>>>> ext 217 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rtk-users mailing list >>>>>>> Rtk-users at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>> >>>>> >>>>> -- >>>>> >>>>> *Johnson Keiriz, PhD >>>>> Senior Software Engineer* >>>>> >>>>> 760 St-Paul W, #101 >>>>> Montreal, QC >>>>> Canada H3C 1M4 >>>>> tel: (514) 843-3861 >>>>> ext 217 >>>>> >>>> >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > > -- > > *Johnson Keiriz, PhD > Senior Software Engineer* > > 760 St-Paul W, #101 > Montreal, QC > Canada H3C 1M4 > tel: (514) 843-3861 > ext 217 > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From jkeiriz at theobjects.com Tue Mar 22 08:21:02 2016 From: jkeiriz at theobjects.com (Johnson Keiriz) Date: Tue, 22 Mar 2016 08:21:02 -0400 Subject: [Rtk-users] Python Wrapping In-Reply-To: <56F0EC90.2060107@creatis.insa-lyon.fr> References: <000f01d18050$14306530$3c912f90$@com> <001b01d18062$581fbb80$085f3280$@com> <002701d18086$c174df10$445e9d30$@com> <56EBB86E.80409@uclouvain.be> <56EBFE6A.2070606@theobjects.com> <56EC0335.50109@uclouvain.be> <56EC4612.3000507@theobjects.com> <56EC5503.7070807@theobjects.com> <56EC559D.1000801@theobjects.com> <56F0EC90.2060107@creatis.insa-lyon.fr> Message-ID: <56F138AE.4090203@theobjects.com> Thanks, On 3/22/2016 2:56 AM, Simon Rit wrote: > Hi, > We have had the same problem with > ConjugateGradientConeBeamReconstructionFilter.json that Fabien pushed > 2 days ago. Maybe have a look at this file to see if you can find some > useful inspiration? Otherwise I'll try to fix your file later. > Simon > > On 18/03/2016 20:23, Johnson Keiriz wrote: >> To be specific: it gives an error at every CUDA filter !!! >> >> On 3/18/2016 3:20 PM, Johnson Keiriz wrote: >>> Hello, >>> I have tried to create a .json file for the >>> *RegularizedConjugateGradientConeBeamReconstructionFilter *and got >>> the below errors while compiling. >>> >>> The json file contains: >>> >>> { >>> "name" : "RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "template_code_filename" : "RTKImageFilter", >>> "template_test_filename" : "ImageFilter", >>> "number_of_inputs" : 2, >>> "doc" : "", >>> "output_image_type" : "TImageType", >>> "pixel_types" : "RealPixelIDTypeList", >>> "filter_type" : >>> "rtk::RegularizedConjugateGradientConeBeamReconstructionFilter", >>> "include_files" : [ >>> "srtkThreeDCircularProjectionGeometry.h" >>> ], >>> "members" : [], >>> "briefdescription" : "Implements regularized conjugate Gradient >>> cone-beam reconstruction.", >>> "detaileddescription" : "" >>> } >>> >>> >>> Error 1 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 2 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 3 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 4 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 5 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 6 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 7 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 8 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 9 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> Error 10 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 77 1 >>> SimpleRTK >>> Error 11 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaRayCastBackProjectionImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkIterativeConeBeamReconstructionFilter.hxx 87 1 >>> SimpleRTK >>> Error 12 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 39 >>> 1 SimpleRTK >>> Error 13 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 40 >>> 1 SimpleRTK >>> Error 14 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaLaplacianImageFilter::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkReconstructionConjugateGradientOperator.hxx 41 >>> 1 SimpleRTK >>> Error 15 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaDisplacedDetectorImageFilter::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 42 1 SimpleRTK >>> Error 16 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConstantVolumeSource::Pointer' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 43 1 SimpleRTK >>> Error 17 error C2679: binary '=' : no operator found which >>> takes a right-hand operand of type >>> 'rtk::CudaConjugateGradientImageFilter_3f::Pointer' (or there is no >>> acceptable conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkConjugateGradientConeBeamReconstructionFilter.hxx >>> 129 1 SimpleRTK >>> Error 18 error C2678: binary '*' : no operator found which >>> takes a left-hand operand of type 'float' (or there is no acceptable >>> conversion) >>> [C:\RTK\BUILD\SimpleRTK-build\Code\BasicFilters\src\SimpleRTKBasicFilters2.vcxproj] >>> c:\rtk\code\rtkMagnitudeThresholdImageFilter.hxx 59 1 SimpleRTK >>> >>> >>> Thanks, >>> Johnson >>> >>> On 3/18/2016 2:16 PM, Johnson Keiriz wrote: >>>> Hello, >>>> I am trying to do the wrapping for the >>>> RegularizedConjugateGradientConeBeamReconstructionFilter, do I need >>>> to wrap all the filters that it uses ? >>>> Is there any guiding document for the wrapping method? >>>> >>>> Regards, >>>> Johnson >>>> >>>> On 3/18/2016 9:31 AM, Cyril Mory wrote: >>>>> Hi again, >>>>> >>>>> You got the SART filter right. As for the conjugate gradient, the >>>>> filter is actually ConjugateGradientConeBeamReconstructionFilter >>>>> (for the 3D non-regularized reconstruction) and >>>>> RegularizedConjugateGradientConeBeamReconstructionFilter (its >>>>> regularized counterpart). >>>>> >>>>> The filter you found, >>>>> FourDConjugateGradientConeBeamReconstructionFilter, is used for 4D >>>>> reconstruction (you need a cardiac or respiratory phase signal). >>>>> Its regularized counterpart is >>>>> FourDROOSTERConeBeamReconstructionFilter. >>>>> >>>>> In addition to those, RTK also has >>>>> ADMMTotalVariationConeBeamReconstructionFilter and >>>>> ADMMWaveletsConeBeamReconstructionFilter, which implement the >>>>> Alternating Direction Method of Multiplier algorithm. >>>>> >>>>> You can find a description of these algorithms in >>>>> https://hal.inria.fr/tel-00985728/document >>>>> >>>>> Note that the SART filter has a m_NumberOfProjectionsPerSubset >>>>> member. Setting it to 1 (default) gives you SART, setting it to n >>>>> with 1 < n < TotalNumberOfProjections gives you OS-SART, and >>>>> setting it to n=TotalNumberOfProjections gives you SIRT. >>>>> >>>>> That's pretty much all there is in RTK at the moment. >>>>> Cyril >>>>> >>>>> On 03/18/2016 02:11 PM, Johnson Keiriz wrote: >>>>>> Hello, >>>>>> Can you please confirm that the following classes are the ones >>>>>> used for the iterative reconstruction: >>>>>> 1 - SART: SARTConeBeamReconstructionFilter >>>>>> 2- Conjugate gradient: >>>>>> FourDConjugateGradientConeBeamReconstructionFilter >>>>>> >>>>>> Is there a 3D conjugate gradient? >>>>>> Are these the only classes for iterative reconstruction? >>>>>> >>>>>> Thanks, >>>>>> Johnson >>>>>> >>>>>> On 3/18/2016 4:12 AM, Cyril Mory wrote: >>>>>>> Hi Johnson, >>>>>>> >>>>>>> Regarding the iterative methods: >>>>>>> - In SART, you can use the CUDA forward and back projectors, but >>>>>>> the rest of the calculation is performed on CPU. We do not use >>>>>>> SART a lot, so we have not fully optimized it. >>>>>>> - Conjugate gradient, on the other hand, is entirely performed >>>>>>> on the GPU. Note that a regularized conjugate gradient >>>>>>> reconstruction filter is also available (with total variation >>>>>>> denoising, wavelets denoising, and positivity enforcement) >>>>>>> >>>>>>> I hope you will find what you need, >>>>>>> Regards, >>>>>>> Cyril >>>>>>> >>>>>>> On 03/17/2016 08:54 PM, Johnson Keiriz wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I did rebuild and now things are working. I tested >>>>>>>> reconstruction with and without the filtering and there were >>>>>>>> differences. Though, I am not sure that filtering have provided >>>>>>>> a better reconstruction. >>>>>>>> >>>>>>>> I want to experiment the iterative methods. Can you please >>>>>>>> confirm for me which iterative method are fully implemented in >>>>>>>> CUDA: is it the conjugate gradient or SART ? >>>>>>>> >>>>>>>> I have noticed that they are not wrapped at all, any guide on >>>>>>>> how to introduce new filters? >>>>>>>> >>>>>>>> Once I have tested my wrapping, I will submit a github >>>>>>>> pull-request. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*simon.rit at gmail.com [mailto:simon.rit at gmail.com] *On >>>>>>>> Behalf Of *Simon Rit >>>>>>>> *Sent:* Thursday, March 17, 2016 1:54 PM >>>>>>>> *To:* Johnson Keiriz >>>>>>>> *Cc:* rtk-users at public.kitware.com >>>>>>>> *Subject:* Re: [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Good! Indeed, many things are not wrapped. There is a trick >>>>>>>> regarding modifications of the wrappings. You need to either >>>>>>>> start from scratch the compilation or delete the file >>>>>>>> SimpleRTK-prefix/src/SimpleRTK-stamp/SimpleRTK-configure. This >>>>>>>> will trigger a reconfiguration of the SimpleRTK and, hopefully, >>>>>>>> account for your modifications. >>>>>>>> >>>>>>>> Don't hesitate to submit a github pull-request when you have >>>>>>>> something working. >>>>>>>> >>>>>>>> Simon >>>>>>>> >>>>>>>> On Thu, Mar 17, 2016 at 4:33 PM, Johnson Keiriz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I found out about the json wrapping files. I added the wrapping >>>>>>>> for all the filters, but I haven?t noticed any effect from >>>>>>>> setting the filters !!! >>>>>>>> >>>>>>>> Any hints ? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *From:*Rtk-users [mailto:rtk-users-bounces at public.kitware.com] >>>>>>>> *On Behalf Of *Johnson Keiriz >>>>>>>> *Sent:* Thursday, March 17, 2016 9:23 AM >>>>>>>> *To:* rtk-users at public.kitware.com; Simon Rit >>>>>>>> *Subject:* [Rtk-users] Python Wrapping >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I am using the Python wrapped version of RTK. I have a question >>>>>>>> regarding the wrapping: >>>>>>>> >>>>>>>> It seems that not all functionality is available, for example: >>>>>>>> for the *CudaFDKConeBeamReconstructionFilter, *I was not able >>>>>>>> to set the cut frequency of the any of the filters >>>>>>>> >>>>>>>> (RamLaK, Cosine, ShepLogan) except for the Hann . Are the >>>>>>>> methods not wrapped ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Johnson >>>>>>>> >>>>>>>> *Description: cid:image002.jpg at 01CB5984.4EABACE0* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Johnson Keiriz, PhD >>>>>>>> Senior Software Engineer* >>>>>>>> >>>>>>>> 760 St-Paul W, #101 >>>>>>>> Montreal, QC >>>>>>>> Canada H3C 1M4 >>>>>>>> tel: (514) 843-3861 >>>>>>>> ext 217 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Rtk-users mailing list >>>>>>>> Rtk-users at public.kitware.com >>>>>>>> http://public.kitware.com/mailman/listinfo/rtk-users >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Johnson Keiriz, PhD >>>>>> Senior Software Engineer* >>>>>> >>>>>> 760 St-Paul W, #101 >>>>>> Montreal, QC >>>>>> Canada H3C 1M4 >>>>>> tel: (514) 843-3861 >>>>>> ext 217 >>>>>> >>>>> >>>> >>>> -- >>>> >>>> *Johnson Keiriz, PhD >>>> Senior Software Engineer* >>>> >>>> 760 St-Paul W, #101 >>>> Montreal, QC >>>> Canada H3C 1M4 >>>> tel: (514) 843-3861 >>>> ext 217 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rtk-users mailing list >>>> Rtk-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >>> -- >>> >>> *Johnson Keiriz, PhD >>> Senior Software Engineer* >>> >>> 760 St-Paul W, #101 >>> Montreal, QC >>> Canada H3C 1M4 >>> tel: (514) 843-3861 >>> ext 217 >>> >>> >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >> >> -- >> >> *Johnson Keiriz, PhD >> Senior Software Engineer* >> >> 760 St-Paul W, #101 >> Montreal, QC >> Canada H3C 1M4 >> tel: (514) 843-3861 >> ext 217 >> >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users > -- *Johnson Keiriz, PhD Senior Software Engineer* 760 St-Paul W, #101 Montreal, QC Canada H3C 1M4 tel: (514) 843-3861 ext 217 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 3930 bytes Desc: not available URL: From shiraska at gmail.com Wed Mar 23 12:46:20 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Wed, 23 Mar 2016 17:46:20 +0100 Subject: [Rtk-users] RTK with curved detector projection images Message-ID: Dear all, Is it possible to use RTK to reconstruct volume from the projections acquired with curved detector? Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Wed Mar 23 12:56:41 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 23 Mar 2016 17:56:41 +0100 Subject: [Rtk-users] RTK with curved detector projection images In-Reply-To: References: Message-ID: <56F2CAC9.8090901@creatis.insa-lyon.fr> Hi, Not at present. We are working on this but this has not been released. Soon although I won't give a date because things have been delayed. Simon