From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wuchao04 at gmail.com Wed Oct 8 07:54:31 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 8 Oct 2014 13:54:31 +0200 Subject: [Rtk-users] coordinates of 3D volume In-Reply-To: References: <003801cfccfd$bd111800$37334800$@gmail.com> Message-ID: Thanks Simon, this approach works perfectly. Regards, Chao 2014-09-10 16:50 GMT+02:00 Simon Rit : > This option works but there is a risk of an additional interpolation by > the resampler and it costs some computing time. The other option I > suggested requires to modify the transform parameter of the source (in this > example, add > > constantImageSource->SetDirection(transform->GetMatrix()); > > where transform is that of Yang's example, then use > itk::ChangeImageInformation > > to reset the transform to identity. > > On Wed, Sep 10, 2014 at 3:47 PM, Yang Kyun Park > wrote: > >> Hi Chao, >> >> >> >> I had the same issue on my work and I?ve managed to fix it by the >> following codes. >> >> I?m not sure this is the optimal way to do it but at least it worked in >> my case. >> >> >> >> (Or you can transform it in 3D Slicer. >> >> In transform menu, you need to apply the following matrix: >> >> 0 0 -1 0 >> >> 1 0 0 0 >> >> 0 1 0 0 >> >> 0 0 0 1 >> >> to the target image, harden the transform then export the image.) >> >> >> >> Best, >> >> YangKyun >> >> >> >> >> >> // OutputImageType = >> >> // streamerBP->GetOutput(): resultant 3D image from rtkfdk reconstruction >> >> >> >> //Same image type from original image -3D & float >> >> OutputImageType::IndexType start_trans; >> >> start_trans[0] = 0; >> >> start_trans[1] = 0; >> >> start_trans[2] = 0; >> >> >> >> OutputImageType::SizeType size_trans; >> >> size_trans[0] = sizeOutput[0]; // X //410 >> >> size_trans[1] = sizeOutput[2]; //Y // 410 >> >> size_trans[2] = sizeOutput[1]; //Z // 120? >> >> >> >> OutputImageType::SpacingType spacing_trans; >> >> spacing_trans[0] = spacing[0]; >> >> spacing_trans[1] = spacing[2]; >> >> spacing_trans[2] = spacing[1]; >> >> >> >> OutputImageType::PointType Origin_trans; >> >> Origin_trans[0] = -0.5* size_trans[0]*spacing_trans[0]; >> >> Origin_trans[1] = -0.5* size_trans[1]*spacing_trans[1]; >> >> Origin_trans[2] = -0.5* size_trans[2]*spacing_trans[2]; >> >> >> >> OutputImageType::RegionType region_trans; >> >> region_trans.SetSize(size_trans); >> >> region_trans.SetIndex(start_trans); >> >> >> >> /* 2) Prepare Target image */ >> >> OutputImageType::Pointer targetImg = streamerBP->GetOutput(); >> >> >> >> /* 3) Configure transform */ >> >> typedef itk::Euler3DTransform< double > TransformType; >> >> TransformType::Pointer transform = TransformType::New(); >> >> >> >> TransformType::ParametersType param; >> >> param.SetSize(6); >> >> //MAXIMUM PARAM NUMBER: 6!!! >> >> param.put(0, 0.0); //rot X // 0.5 = PI/2 >> >> param.put(1, itk::Math::pi/2.0);//rot Y >> >> param.put(2, itk::Math::pi/-2.0);//rot Z >> >> param.put(3, 0.0); // Trans X mm >> >> param.put(4, 0.0); // Trans Y mm >> >> param.put(5, 0.0); // Trans Z mm >> >> >> >> TransformType::ParametersType fixedParam(3); //rotation center >> >> fixedParam.put(0,0); >> >> fixedParam.put(1,0); >> >> fixedParam.put(2,0); >> >> >> >> transform->SetParameters(param); >> >> transform->SetFixedParameters(fixedParam); //Center of the >> Transform >> >> >> >> cout << "Transform matrix:" << " " << endl; >> >> cout << transform->GetMatrix() << std::endl; >> >> >> >> typedef itk::ResampleImageFilter >> ResampleFilterType; >> >> ResampleFilterType::Pointer resampler = ResampleFilterType::New(); >> >> >> //OutputImageType::RegionType fixedImg_Region = >> fixedImg->GetLargestPossibleRegion().GetSize(); >> >> >> >> resampler->SetInput(targetImg); >> >> resampler->SetSize(size_trans); >> >> resampler->SetOutputOrigin( Origin_trans); //Lt Top Inf of Large >> Canvas >> >> resampler->SetOutputSpacing( spacing_trans ); // 1 1 1 >> >> resampler->SetOutputDirection( targetImg->GetDirection() ); //image >> normal? >> >> resampler->SetTransform(transform); >> >> >> >> //LR flip >> >> >> >> cout << "LR flip filter is being applied" << endl; >> >> >> >> typedef itk::FlipImageFilter< OutputImageType > FilterType; >> >> >> >> FilterType::Pointer flipFilter = FilterType::New(); >> >> typedef FilterType::FlipAxesArrayType FlipAxesArrayType; >> >> >> >> FlipAxesArrayType arrFlipAxes; >> >> arrFlipAxes[0] = 1; >> >> arrFlipAxes[1] = 0; >> >> arrFlipAxes[2] = 0; >> >> >> >> flipFilter->SetFlipAxes(arrFlipAxes); >> >> flipFilter->SetInput(resampler->GetOutput()); >> >> flipFilter->Update(); >> >> >> >> //Use flipFilter->GetOutput() for further process >> >> >> >> >> >> >> >> *From:* Rtk-users [mailto:rtk-users-bounces at public.kitware.com] *On >> Behalf Of *Simon Rit >> *Sent:* Wednesday, September 10, 2014 8:39 AM >> *To:* Chao Wu >> *Cc:* rtk-users at openrtk.org >> *Subject:* Re: [Rtk-users] coordinates of 3D volume >> >> >> >> Hi, >> >> I wish there was a single industrial standard... You have the DICOM >> standard in mind and I used an IEC standard (see wiki). You can play with >> the --direction option to orientate the voxel axes of your image (see >> itk::Image documentation) and then reset the direction of your output image >> to identity, I think that will do what you want. >> >> Simon >> >> >> >> On Wed, Sep 10, 2014 at 1:35 PM, Chao Wu wrote: >> >> Hi all, >> >> >> >> I see that rtk use certain industrial standard for the coordinates of 2D >> projections and 3D volumes. However in medical imaging, the xy planes of a >> volume are usually transaxial slices while the 3rd dimension is aligned >> with the axis of rotation. I would like to switch to this coordinates in my >> own code. Is there anyone who can give me some comments and suggestions >> about where to start? Thanks. >> >> >> >> Regards, >> >> Chao >> >> >> _______________________________________________ >> Rtk-users 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 croow at yahoo.com Wed Oct 8 17:24:33 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:24:33 -0700 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Message-ID: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks From theday79 at gmail.com Wed Oct 8 17:31:13 2014 From: theday79 at gmail.com (Yang-Kyun Park) Date: Wed, 8 Oct 2014 17:31:13 -0400 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, im using a cuda v4.2 and it works well for me. YangKyun On Oct 8, 2014 5:27 PM, "M Miller via Rtk-users" < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 croow at yahoo.com Wed Oct 8 17:28:56 2014 From: croow at yahoo.com (M Miller) Date: Wed, 8 Oct 2014 14:28:56 -0700 Subject: [Rtk-users] reconstruct a volume from a series of .tifs Message-ID: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> I'm trying to reconstruct a volume from a series of .tif projections and have a few questions. The 360 projections are each 2048x2000 floats, with transmission intensity values. The pixel spacing on the detector is 0.048mm. The following commands do produce a volume, but the scale is wrong. The --proj_iso_* values below are guesses. rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 rtkbackprojections.exe --geometry=r:\data\geo.xml --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha --bp=CudaBackProjection --spacing=.5 --dimension=500 How does rtk know the pixel spacing of the input images? I thought I could simplify the problem by using rtksubselect to convert the tifs into a mhd/raw set before reconstruction. rtksubselect.exe --geometry=r:\data\geo.xml --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd --path=R:\data\projections -r .tif$ After a surprisingly long wait an mhd/raw pair are produced. (Why does it use so much memory? While running rtksubselect needed about 24GB, when all the projection data is <6GB and the output file is <6GB.) The output mhd file has the ElementSpacing = 0.254. Where did that come from? Using this mystery 0.254, the true spacing of 0.048, and the true proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There must be an easier way. So, what is the correct way to reconstruct these projections into a volume? Thanks From simon.rit at creatis.insa-lyon.fr Thu Oct 9 02:31:29 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:31:29 +0200 Subject: [Rtk-users] reconstruct a volume from a series of .tifs In-Reply-To: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> References: <1412803736.93061.YahooMailBasic@web120001.mail.ne1.yahoo.com> Message-ID: Hi, RTK takes the spacing given by the tiff reader of itk. For such questions, I strongly suggest to read the code, that's the beauty of open source codes! To help you a bit there: - rtk::ProjectionsReader is the base class for converting images to line integrals. It's always two-step: first, it reads in the projections (m_RawDataReader), second it converts it to line integrals (m_RawToProjectionsFilter). Spacing comes from the raw data reader, which is here TIFFImageIO. - itk::TIFFImageIO::ReadImageInformation is quite complex but slightly readable. It seems to read in some spacing information, units, etc. m_XResolution is read from TIFFTAG_XRESOLUTION is defined in Modules//ThirdParty/TIFF/src/itktiff/tiff.h and it seems to be the tag 282 in the tiff image. To correct this problem since apparently your tiff files are not according to itk expectations, you could change the spacing after reading in the projections by inserting a itk::ChangeInformationImageFilter in the pipeline, after rtk::ProjectionsReader. Regarding memory issues, the solution is probably to stream things, as is done in many applications, e.g., rtkwangdisplaceddetectorweighting, with the --divisions option. I think it's quite straightforward to add it in rtksubselect but let me know if you can't figure it out. And yes, I have no doubt there is a way to reconstruct these projections... if they are tomographic projections! Good luck with this, Simon On Wed, Oct 8, 2014 at 11:28 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > I'm trying to reconstruct a volume from a series of .tif projections and > have a few questions. > The 360 projections are each 2048x2000 floats, with transmission intensity > values. The pixel spacing on the detector is 0.048mm. > The following commands do produce a volume, but the scale is wrong. The > --proj_iso_* values below are guesses. > > rtksimulatedgeometry.exe --output=r:\data\geo.xml --nproj=360 --arc=360 > --sdd=1860 --sid=1102 --proj_iso_x=-285.496 --proj_iso_y=-260.096 > rtkbackprojections.exe --geometry=r:\data\geo.xml > --path=R:\data\projections -r .tif$ --output=r:\data\fromTifs.mha > --bp=CudaBackProjection --spacing=.5 --dimension=500 > > How does rtk know the pixel spacing of the input images? > I thought I could simplify the problem by using rtksubselect to convert > the tifs into a mhd/raw set before reconstruction. > > rtksubselect.exe --geometry=r:\data\geo.xml > --out_geometry=r:\data\geo_sub.xml --out_proj=r:\data\proj_sub.mhd > --path=R:\data\projections -r .tif$ > > After a surprisingly long wait an mhd/raw pair are produced. > (Why does it use so much memory? While running rtksubselect needed about > 24GB, when all the projection data is <6GB and the output file is <6GB.) > The output mhd file has the ElementSpacing = 0.254. Where did that come > from? > Using this mystery 0.254, the true spacing of 0.048, and the true > proj_iso_x of -4.8, I calculated the working proj_iso_x value above. There > must be an easier way. > > So, what is the correct way to reconstruct these projections into a volume? > > Thanks > _______________________________________________ > Rtk-users 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 Oct 9 02:34:38 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 9 Oct 2014 08:34:38 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users < rtk-users at public.kitware.com> wrote: > Can RTK be built with CUDA 6.5 and VS2013? > > (Using RTK source downloaded 10.7.14) > CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. > To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must > be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA > will probably require the other -gencode lines to be modified. > > Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in > "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the > "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: > CUDA ERROR: invalid argument". > Other modes including bp=CudaBackProjection work fine under the same > conditions. > > Which versions of CUDA are supported by RTK? > > > Thanks > _______________________________________________ > Rtk-users 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 sebastien.brousmiche at uclouvain.be Thu Oct 9 03:28:34 2014 From: sebastien.brousmiche at uclouvain.be (=?UTF-8?Q?S=C3=A9bastien_Brousmiche?=) Date: Thu, 9 Oct 2014 09:28:34 +0200 Subject: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? In-Reply-To: References: <1412803473.2539.YahooMailBasic@web120005.mail.ne1.yahoo.com> Message-ID: <002101cfe392$a24adfa0$e6e09ee0$@uclouvain.be> Hi, I?m using VS2013 with CUDA 6.5. Apart from the fact that you indeed have to remove the line ?-gencode arch=compute_10,code=sm_10? in the FindCuda_wrap.cmake, everything works fine. I also had to upgrade the drivers (to 340.62) to get the 6.5 supports but I?m not sure it applies to you. I?ve a Tesla card with 1.2 compute capability. Have you tried running the examples coming with the cuda toolkit? As you mentioned and as specified in the 6.5 release note, 1.x gpu won?t be supported anymore starting CUDA 7.x. S?bastien From: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] On Behalf Of Simon Rit Sent: jeudi 9 octobre 2014 08:35 To: M Miller Cc: rtk-users at public.kitware.com Subject: Re: [Rtk-users] Can RTK be built with CUDA 6.5 and VS2013? Hi, I haven't tried this combination, not even each one separately. But this is odd that CudaFDKBackprojectionImageFilter fails and CudaBackProjectionImageFilter succeeds, it's almost the same code. Can you check if the error is not somewhere else by putting the CUDA_CHECK_ERROR at the beginning of the function? (line 193). If you can't find the error, I would suggest to send a set of command line that produces the error, similar to what we use in our wiki examples (here for example). Thanks for the report, Simon On Wed, Oct 8, 2014 at 11:24 PM, M Miller via Rtk-users wrote: Can RTK be built with CUDA 6.5 and VS2013? (Using RTK source downloaded 10.7.14) CUDA 6.5 has obseleted sm_10 and deprecated sm_11, sm_12, and sm_13. To build rtkcuda the parameter "-gencode arch=compute_10,code=sm_10" must be removed from FindCUDA_wrap.cmake (line 56). The next version of CUDA will probably require the other -gencode lines to be modified. Calling rtkbackprojections with bp=CudaFDKBackProjection crashes in "CUDA_reconstruct_conebeam". Inserting a CUDA_CHECK_ERROR after the "cudaMemcpyToArray" (about line 203) provides the description "itk::ERROR: CUDA ERROR: invalid argument". Other modes including bp=CudaBackProjection work fine under the same conditions. Which versions of CUDA are supported by RTK? Thanks _______________________________________________ Rtk-users 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 Fri Oct 10 04:58:04 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Fri, 10 Oct 2014 10:58:04 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure Message-ID: Hi all, I am trying the new cuda displaced detector filter but got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) at the end of the code, but since this error type is not registered with cudaFree(), it would be from previous, asynchronous launches. By using cudaDeviceSynchronize() I found the error coming after calling kernel_displaced_weight<<<...>>>(...). One interesting thing is that when the error occurs depends on the number of projections processed at once (controlled by the --subset=N option of rtkfdk.exe for example). If I use subset=1 then it fails right with the first projection; if subset=2 it fails at the 16th run when processing the 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 (default), at the 6th run; and so on. The input region of each projection is about 1944x200 (the 2nd dimension differs a little bit of course) and the output region is then about 3888x200. A GTX580 card is used. Any suggestions and comments on this? Thanks. Regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 10 08:30:35 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 10 Oct 2014 14:30:35 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Thanks for the report, it's new so we might have left special cases behind... sorry. Is this something that occurs when launching rtkfdk, rtkwangdisplaceddetectorweighting or one of your own applications? It would be very useful if you could manage to reproduce this with a set of command lines that would simulate data first and then apply the weighting, similar to what's here for example. Regards, Simon On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > Hi all, > > I am trying the new cuda displaced detector filter but > got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) > at the end of the code, but since this error type is not registered with > cudaFree(), it would be from previous, asynchronous launches. By > using cudaDeviceSynchronize() I found the error coming after calling > kernel_displaced_weight<<<...>>>(...). > > One interesting thing is that when the error occurs depends on the number > of projections processed at once (controlled by the --subset=N option of > rtkfdk.exe for example). If I use subset=1 then it fails right with the > first projection; if subset=2 it fails at the 16th run when processing the > 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 > (default), at the 6th run; and so on. > > The input region of each projection is about 1944x200 (the 2nd dimension > differs a little bit of course) and the output region is then about > 3888x200. A GTX580 card is used. > > Any suggestions and comments on this? Thanks. > > Regards, > Chao > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Tue Oct 14 04:01:37 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 14 Oct 2014 10:01:37 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, Yesterday, I investigated the dynamic analysis log and found a problem in the filter that has been corrected (see commit here ). Could you check if it fixes your issue please? Thanks, Simon On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit wrote: > Hi Chao, > Thanks for the report, it's new so we might have left special cases > behind... sorry. Is this something that occurs when launching rtkfdk, > rtkwangdisplaceddetectorweighting or one of your own applications? > It would be very useful if you could manage to reproduce this with a set > of command lines that would simulate data first and then apply the > weighting, similar to what's here > for example. > Regards, > Simon > > On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: > >> Hi all, >> >> I am trying the new cuda displaced detector filter but >> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >> at the end of the code, but since this error type is not registered with >> cudaFree(), it would be from previous, asynchronous launches. By >> using cudaDeviceSynchronize() I found the error coming after calling >> kernel_displaced_weight<<<...>>>(...). >> >> One interesting thing is that when the error occurs depends on the number >> of projections processed at once (controlled by the --subset=N option of >> rtkfdk.exe for example). If I use subset=1 then it fails right with the >> first projection; if subset=2 it fails at the 16th run when processing the >> 31st and 32nd projections; if subset=4, at the 14th run; if subset=16 >> (default), at the 6th run; and so on. >> >> The input region of each projection is about 1944x200 (the 2nd dimension >> differs a little bit of course) and the output region is then about >> 3888x200. A GTX580 card is used. >> >> Any suggestions and comments on this? Thanks. >> >> Regards, >> Chao >> >> _______________________________________________ >> Rtk-users 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 Tue Oct 14 07:42:49 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Tue, 14 Oct 2014 13:42:49 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Thanks Simon, however this does not solve the issue here. I'll go back to this later to try to reproduce it with sample data, but now I am a bit busy with something else. Sorry at the moment. Regards, Chao 2014-10-14 10:01 GMT+02:00 Simon Rit : > Hi Chao, > Yesterday, I investigated the dynamic analysis log and found a problem in > the filter that has been corrected (see commit here > ). > Could you check if it fixes your issue please? > Thanks, > Simon > > On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit > wrote: > >> Hi Chao, >> Thanks for the report, it's new so we might have left special cases >> behind... sorry. Is this something that occurs when launching rtkfdk, >> rtkwangdisplaceddetectorweighting or one of your own applications? >> It would be very useful if you could manage to reproduce this with a set >> of command lines that would simulate data first and then apply the >> weighting, similar to what's here >> for example. >> Regards, >> Simon >> >> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >> >>> Hi all, >>> >>> I am trying the new cuda displaced detector filter but >>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>> at the end of the code, but since this error type is not registered with >>> cudaFree(), it would be from previous, asynchronous launches. By >>> using cudaDeviceSynchronize() I found the error coming after calling >>> kernel_displaced_weight<<<...>>>(...). >>> >>> One interesting thing is that when the error occurs depends on the >>> number of projections processed at once (controlled by the --subset=N >>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>> with the first projection; if subset=2 it fails at the 16th run when >>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>> subset=16 (default), at the 6th run; and so on. >>> >>> The input region of each projection is about 1944x200 (the 2nd dimension >>> differs a little bit of course) and the output region is then about >>> 3888x200. A GTX580 card is used. >>> >>> Any suggestions and comments on this? Thanks. >>> >>> Regards, >>> Chao >>> >>> _______________________________________________ >>> Rtk-users 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 Wed Oct 22 12:29:41 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Wed, 22 Oct 2014 18:29:41 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Chao, I have hunted the bug and I fixed an issue: https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 Can you try again? Simon On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > Thanks Simon, however this does not solve the issue here. > I'll go back to this later to try to reproduce it with sample data, but > now I am a bit busy with something else. Sorry at the moment. > > Regards, Chao > > 2014-10-14 10:01 GMT+02:00 Simon Rit : > >> Hi Chao, >> Yesterday, I investigated the dynamic analysis log and found a problem in >> the filter that has been corrected (see commit here >> ). >> Could you check if it fixes your issue please? >> Thanks, >> Simon >> >> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >> simon.rit at creatis.insa-lyon.fr> wrote: >> >>> Hi Chao, >>> Thanks for the report, it's new so we might have left special cases >>> behind... sorry. Is this something that occurs when launching rtkfdk, >>> rtkwangdisplaceddetectorweighting or one of your own applications? >>> It would be very useful if you could manage to reproduce this with a set >>> of command lines that would simulate data first and then apply the >>> weighting, similar to what's here >>> for example. >>> Regards, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>> >>>> Hi all, >>>> >>>> I am trying the new cuda displaced detector filter but >>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>> at the end of the code, but since this error type is not registered with >>>> cudaFree(), it would be from previous, asynchronous launches. By >>>> using cudaDeviceSynchronize() I found the error coming after calling >>>> kernel_displaced_weight<<<...>>>(...). >>>> >>>> One interesting thing is that when the error occurs depends on the >>>> number of projections processed at once (controlled by the --subset=N >>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>> with the first projection; if subset=2 it fails at the 16th run when >>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>> subset=16 (default), at the 6th run; and so on. >>>> >>>> The input region of each projection is about 1944x200 (the 2nd >>>> dimension differs a little bit of course) and the output region is then >>>> about 3888x200. A GTX580 card is used. >>>> >>>> Any suggestions and comments on this? Thanks. >>>> >>>> Regards, >>>> Chao >>>> >>>> _______________________________________________ >>>> Rtk-users 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 Oct 22 16:38:24 2014 From: wuchao04 at gmail.com (Chao Wu) Date: Wed, 22 Oct 2014 22:38:24 +0200 Subject: [Rtk-users] CUDA displaced detector filter failure In-Reply-To: References: Message-ID: Hi Simon, The error went away! Thanks for the great work. Regards, Chao 2014-10-22 18:29 GMT+02:00 Simon Rit : > Hi Chao, > I have hunted the bug and I fixed an issue: > > https://github.com/SimonRit/RTK/commit/415756016d25edaf0fe999a46f3b5ad231b0e032 > Can you try again? > Simon > > On Tue, Oct 14, 2014 at 1:42 PM, Chao Wu wrote: > >> Thanks Simon, however this does not solve the issue here. >> I'll go back to this later to try to reproduce it with sample data, but >> now I am a bit busy with something else. Sorry at the moment. >> >> Regards, Chao >> >> 2014-10-14 10:01 GMT+02:00 Simon Rit : >> >>> Hi Chao, >>> Yesterday, I investigated the dynamic analysis log and found a problem >>> in the filter that has been corrected (see commit here >>> ). >>> Could you check if it fixes your issue please? >>> Thanks, >>> Simon >>> >>> On Fri, Oct 10, 2014 at 2:30 PM, Simon Rit < >>> simon.rit at creatis.insa-lyon.fr> wrote: >>> >>>> Hi Chao, >>>> Thanks for the report, it's new so we might have left special cases >>>> behind... sorry. Is this something that occurs when launching rtkfdk, >>>> rtkwangdisplaceddetectorweighting or one of your own applications? >>>> It would be very useful if you could manage to reproduce this with a >>>> set of command lines that would simulate data first and then apply the >>>> weighting, similar to what's here >>>> for example. >>>> Regards, >>>> Simon >>>> >>>> On Fri, Oct 10, 2014 at 10:58 AM, Chao Wu wrote: >>>> >>>>> Hi all, >>>>> >>>>> I am trying the new cuda displaced detector filter but >>>>> got cudaErrorLaunchFailure. This error was returned by cudaFree(dev_geom) >>>>> at the end of the code, but since this error type is not registered with >>>>> cudaFree(), it would be from previous, asynchronous launches. By >>>>> using cudaDeviceSynchronize() I found the error coming after calling >>>>> kernel_displaced_weight<<<...>>>(...). >>>>> >>>>> One interesting thing is that when the error occurs depends on the >>>>> number of projections processed at once (controlled by the --subset=N >>>>> option of rtkfdk.exe for example). If I use subset=1 then it fails right >>>>> with the first projection; if subset=2 it fails at the 16th run when >>>>> processing the 31st and 32nd projections; if subset=4, at the 14th run; if >>>>> subset=16 (default), at the 6th run; and so on. >>>>> >>>>> The input region of each projection is about 1944x200 (the 2nd >>>>> dimension differs a little bit of course) and the output region is then >>>>> about 3888x200. A GTX580 card is used. >>>>> >>>>> Any suggestions and comments on this? Thanks. >>>>> >>>>> Regards, >>>>> Chao >>>>> >>>>> _______________________________________________ >>>>> Rtk-users 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 hsieandy at gmail.com Fri Oct 24 03:50:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 18:50:26 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt Message-ID: Hi Simon & RTK developers & the RTK community, I have a question about how delta is calculated in rtkParkerShortScanImageFilter.txt. The itFirstAngle and the itLastAngle were used to find the first and last angular values for calculating delta. However I noticed that at line 93 itFirstAngle is acquired by: itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; itFirstAngle = (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; Why are the second and third lines duplicated? Wouldn't this point to the "second" angle instead? And also for itLastAngle at line 99: itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); itLastAngle = (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; Why is the second line needed here? Wouldn't this point to the "second last" angle instead? (Since maxAngularGapPos was caluclated with GetAngularGapsWithNext). I did test this with a 0-200 deg short scan, and found that firatAngle and lastAngle weren't equal to 0 and 200, but were calculated to be the second and second last angles instead. Is there any reason for this implementation? Thank you. Cheers, Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Fri Oct 24 04:24:58 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Fri, 24 Oct 2014 10:24:58 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, Good question. Yes there is a reason. In another part of the code, rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry angles is discretized by taking into account the AngularGaps so that the algorithm can cope with variations in the rotation speed. Therefore, the two projections around the large angular gap introduced by the short scan will be overweighted because it is not aware of a short scan weighting elsewhere. The solution currently implemented discards the projections around the gap, as you have correctly noticed. There is a better solution which would avoid throwing away these two projections but this was less easy to introduce in the pipeline and in most cases there is a sufficient number of projections anyway. But you could try to modify this if you're dealing with a very few projections. Regards, Simon On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > Hi Simon & RTK developers & the RTK community, > > I have a question about how delta is calculated in > rtkParkerShortScanImageFilter.txt. > > The itFirstAngle and the itLastAngle were used to find the first and last > angular values for calculating delta. > > However I noticed that at line 93 itFirstAngle is acquired by: > > itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > itFirstAngle = > (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; > > Why are the second and third lines duplicated? Wouldn't this point to the > "second" angle instead? > > And also for itLastAngle at line 99: > > itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); > itLastAngle = > (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; > > Why is the second line needed here? Wouldn't this point to the "second > last" angle instead? (Since maxAngularGapPos was caluclated > with GetAngularGapsWithNext). > > I did test this with a 0-200 deg short scan, and found that firatAngle and > lastAngle weren't equal to 0 and 200, but were calculated to be the second > and second last angles instead. > Is there any reason for this implementation? > > Thank you. > > Cheers, > Andy > > _______________________________________________ > Rtk-users 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 hsieandy at gmail.com Fri Oct 24 06:13:29 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Fri, 24 Oct 2014 21:13:29 +1100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Simon, Thanks so much. That answered my question. Yes, it seems like in most cases discarding those two projections doesn't affect the reconstruction much. However, for some 4D thoracic reconstruction cases, especially when amplitude binning is used, the gap between the 1st and 2nd projection can get pretty large, in which case discarding those two projections could lead to an unnecessary "insufficient data for proper Parker weighting" warning as well as some crazy weighting values that produce massive streaks. The workaround I might try is to have the ProjectionGeometry object determine whether it's dealing with a short scan or not first. And in the case it is a short scan, let it calculate the angular gaps differently for the first and last angles. My first thought would be to use something like this: Gap_first = (second angle - first angle) * 2 (Just use the gap on one side) or Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle smaller than but closest to (first angle + 180) ) ) (find its closest neighbour 180-deg across) However, I'm not sure if those are appropriate alternative ways to calculate the gaps for the boundary angles in order for a reasonable FDK weighting. I would love to know if you have any thought on this. Thanks :) Cheers, Andy 2014-10-24 19:24 GMT+11:00 Simon Rit : > Hi Andy, > Good question. Yes there is a reason. In another part of the code, > rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry > angles is discretized by taking into account the AngularGaps so that the > algorithm can cope with variations in the rotation speed. Therefore, the > two projections around the large angular gap introduced by the short scan > will be overweighted because it is not aware of a short scan weighting > elsewhere. The solution currently implemented discards the projections > around the gap, as you have correctly noticed. > There is a better solution which would avoid throwing away these two > projections but this was less easy to introduce in the pipeline and in most > cases there is a sufficient number of projections anyway. But you could try > to modify this if you're dealing with a very few projections. > Regards, > Simon > > On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: > >> Hi Simon & RTK developers & the RTK community, >> >> I have a question about how delta is calculated in >> rtkParkerShortScanImageFilter.txt. >> >> The itFirstAngle and the itLastAngle were used to find the first and last >> angular values for calculating delta. >> >> However I noticed that at line 93 itFirstAngle is acquired by: >> >> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> itFirstAngle = >> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >> >> Why are the second and third lines duplicated? Wouldn't this point to the >> "second" angle instead? >> >> And also for itLastAngle at line 99: >> >> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >> itLastAngle = >> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >> >> Why is the second line needed here? Wouldn't this point to the "second >> last" angle instead? (Since maxAngularGapPos was caluclated >> with GetAngularGapsWithNext). >> >> I did test this with a 0-200 deg short scan, and found that firatAngle >> and lastAngle weren't equal to 0 and 200, but were calculated to be the >> second and second last angles instead. >> Is there any reason for this implementation? >> >> Thank you. >> >> Cheers, >> Andy >> >> _______________________________________________ >> Rtk-users 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 jean.hoskovec at gmail.com Fri Oct 24 11:21:27 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Fri, 24 Oct 2014 17:21:27 +0200 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I was recently dealing with a similar problem in a different context (180? backprojection with irregular sampling and how to handle the first and last gaps) and what worked for me was Gap_first = (second angle - first angle) / 2 - lower integration limit and, analogically, Gap_last = upper integration limit - (last angle - second last angle) / 2 with the integration limits being arbitrary set where I wanted them. The idea behind this was that a continuous projection value we are miming in the discrete integral should always be represented by the closest projection we have, with a known angular segment to cover. However, that was a DBP-type algorithm, for which the exact integration limits are extremely important, it may be different in the context of a short scan. But just in case you might find this useful... Cheers, Jan 2014-10-24 12:13 GMT+02:00 Andy Shieh : > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning as > well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - (angle > smaller than but closest to (first angle + 180) ) ) (find its > closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to calculate > the gaps for the boundary angles in order for a reasonable FDK weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : >> >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the two >> projections around the large angular gap introduced by the short scan will >> be overweighted because it is not aware of a short scan weighting elsewhere. >> The solution currently implemented discards the projections around the gap, >> as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >>> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and last >>> angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to the >>> "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated with >>> GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users mailing list >>> Rtk-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/rtk-users >>> >> > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Sat Oct 25 09:41:26 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Sun, 26 Oct 2014 00:41:26 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan, Thanks for sharing. This does seem useful to me, but I'm not sure if I understand your method correctly. For your lower and upper integration limit, do you mean the limit values for the angular range that you are "expecting"? For example if you are expecting a 0-180 deg scan (although the first and last angles might not be 0 and 180 due to sampling), lower/upper integration limit would be 0 and 180 deg? And why is the division 2 needed there? I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the weighting is "nextAngle - previousAngle" for a certain projection. In this case I would expect Gap_first to be Gap_first = second_angle - lower_integration_limit (As the lower integration limit is kind of like the "virtual angle" preceding the first angle?) Thanks for your help :) Cheers, Andy > Date: Fri, 24 Oct 2014 17:21:27 +0200 > From: Jan Hoskovec > To: Andy Shieh > Cc: "rtk-users at public.kitware.com" > Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > rtkParkerShortScanImageFilter.txt > Message-ID: > DhwrwzNLg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Andy, > > I was recently dealing with a similar problem in a different context > (180? backprojection with irregular sampling and how to handle the > first and last gaps) and what worked for me was > > Gap_first = (second angle - first angle) / 2 - lower integration limit > > and, analogically, > > Gap_last = upper integration limit - (last angle - second last angle) / 2 > > with the integration limits being arbitrary set where I wanted them. > The idea behind this was that a continuous projection value we are > miming in the discrete integral should always be represented by the > closest projection we have, with a known angular segment to cover. > > However, that was a DBP-type algorithm, for which the exact > integration limits are extremely important, it may be different in the > context of a short scan. But just in case you might find this > useful... > > Cheers, > > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 03:48:21 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 08:48:21 +0100 Subject: [Rtk-users] itFirstAngle and itLastAngle in rtkParkerShortScanImageFilter.txt In-Reply-To: References: Message-ID: Hi Andy, I don't have a strong opinion. For the design, letting ProjectionGeometry tell if it's a short scan is one option. The other is to cancel out the angular weighting of rtkFDKWeightProjectionFilter in rtkParkerShortScan and create a new weighting. The advantage of the latter option is to keep things compartimented while the other shares the definition of a short scan accross filters. I don't think there is a good answer to what is the best weighting. I think that using the angular gap of the two projections adjacent to the large gap is good enough, you just have to make sure then that the start of the scan is half this gap before this first angle (and idem on the opposite side). My gut feeling is that it won't make a big difference for Parker weighting. Simon On Fri, Oct 24, 2014 at 12:13 PM, Andy Shieh wrote: > Hi Simon, > > Thanks so much. That answered my question. > > Yes, it seems like in most cases discarding those two projections doesn't > affect the reconstruction much. > However, for some 4D thoracic reconstruction cases, especially when > amplitude binning is used, the gap between the 1st and 2nd projection can > get pretty large, in which case discarding those two projections could lead > to an unnecessary "insufficient data for proper Parker weighting" warning > as well as some crazy weighting values that produce massive streaks. > > The workaround I might try is to have the ProjectionGeometry object > determine whether it's dealing with a short scan or not first. And in the > case it is a short scan, let it calculate the angular gaps differently for > the first and last angles. > > My first thought would be to use something like this: > > Gap_first = (second angle - first angle) * 2 (Just use the > gap on one side) > > or > > Gap_first = (second angle - first angle) + ( (first angle + 180) - > (angle smaller than but closest to (first angle + 180) ) ) > (find its closest neighbour 180-deg across) > > > However, I'm not sure if those are appropriate alternative ways to > calculate the gaps for the boundary angles in order for a reasonable FDK > weighting. > > I would love to know if you have any thought on this. Thanks :) > > Cheers, > Andy > > 2014-10-24 19:24 GMT+11:00 Simon Rit : > >> Hi Andy, >> Good question. Yes there is a reason. In another part of the code, >> rtkFDKWeightProjectionFilter.txx, the continuous integral over the gantry >> angles is discretized by taking into account the AngularGaps so that the >> algorithm can cope with variations in the rotation speed. Therefore, the >> two projections around the large angular gap introduced by the short scan >> will be overweighted because it is not aware of a short scan weighting >> elsewhere. The solution currently implemented discards the projections >> around the gap, as you have correctly noticed. >> There is a better solution which would avoid throwing away these two >> projections but this was less easy to introduce in the pipeline and in most >> cases there is a sufficient number of projections anyway. But you could try >> to modify this if you're dealing with a very few projections. >> Regards, >> Simon >> >> On Fri, Oct 24, 2014 at 9:50 AM, Andy Shieh wrote: >> >>> Hi Simon & RTK developers & the RTK community, >>> >>> I have a question about how delta is calculated in >>> rtkParkerShortScanImageFilter.txt. >>> >>> The itFirstAngle and the itLastAngle were used to find the first and >>> last angular values for calculating delta. >>> >>> However I noticed that at line 93 itFirstAngle is acquired by: >>> >>> itFirstAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> itFirstAngle = >>> (++itFirstAngle==sortedAngles.end())?sortedAngles.begin():itFirstAngle; >>> >>> Why are the second and third lines duplicated? Wouldn't this point to >>> the "second" angle instead? >>> >>> And also for itLastAngle at line 99: >>> >>> itLastAngle = sortedAngles.find(rotationAngles[maxAngularGapPos]); >>> itLastAngle = >>> (itLastAngle==sortedAngles.begin())?--sortedAngles.end():--itLastAngle; >>> >>> Why is the second line needed here? Wouldn't this point to the "second >>> last" angle instead? (Since maxAngularGapPos was caluclated >>> with GetAngularGapsWithNext). >>> >>> I did test this with a 0-200 deg short scan, and found that firatAngle >>> and lastAngle weren't equal to 0 and 200, but were calculated to be the >>> second and second last angles instead. >>> Is there any reason for this implementation? >>> >>> Thank you. >>> >>> Cheers, >>> Andy >>> >>> _______________________________________________ >>> Rtk-users 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 padraig.looney at gmail.com Mon Oct 27 08:23:36 2014 From: padraig.looney at gmail.com (Padraig Looney) Date: Mon, 27 Oct 2014 12:23:36 +0000 Subject: [Rtk-users] C++11 Message-ID: Dear all, Is it possible to build RTK using C++11. I have built ITK using the flag *VCL_INCLUDE_CXX_0X:BOOL=ON* I tried SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") in the CMakeLists.txt for RTK but I can't build. I am just looking to use lambda expressions like *std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ return d++;} );* in my code and I cannot build. I am assuming the issue is that RTK is not built using C++11 Best wishes P?draig -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Oct 27 08:43:11 2014 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 27 Oct 2014 13:43:11 +0100 Subject: [Rtk-users] C++11 In-Reply-To: References: Message-ID: Hi Padraig, Indeed, we don't use C++11. I don't know what is the consequence of such a change but don't hesitate to suggest modifications if you have to make some to serve your purpose. In ITK, VCL_INCLUDE_CXX_0X is only for one module, I don't think it impacts the rest of the platform more than it does for RTK. Simon On Mon, Oct 27, 2014 at 1:23 PM, Padraig Looney wrote: > Dear all, > > Is it possible to build RTK using C++11. I have built ITK using the flag > > VCL_INCLUDE_CXX_0X:BOOL=ON > > I tried > > > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") > > in the CMakeLists.txt for RTK but I can't build. > > > I am just looking to use lambda expressions like > > > std::for_each(m_GantryAngles.begin(), m_GantryAngles.end(), [](double &d){ > return d++;} ); > > in my code and I cannot build. I am assuming the issue is that RTK is not > built using C++11 > > Best wishes > > P?draig > > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From jean.hoskovec at gmail.com Mon Oct 27 09:34:32 2014 From: jean.hoskovec at gmail.com (Jan Hoskovec) Date: Mon, 27 Oct 2014 14:34:32 +0100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Andy, I'm sorry not to have replied earlier. For the precisions you wanted, 1) your intuition is right, the upper and lower integration limits are the values you are "expecting", the values delimiting the angular range you want to cover (whatever is the actual sampling). 2) The division by two is there because in my approach, the "zone of influence" of each sampled projections begins and ends halfway between the sampled value of the gantry angle and the next / preceding sample. The weights of other than first and last samples simplify to " (next angle - previous angle) / 2" for me. Hope this would help (unless, of course, you've found a better option during the weekend :-) ). Cheers, Jan 2014-10-25 15:41 GMT+02:00 Andy Shieh : > Hi Jan, > > Thanks for sharing. > This does seem useful to me, but I'm not sure if I understand your method > correctly. > > For your lower and upper integration limit, do you mean the limit values for > the angular range that you are "expecting"? > For example if you are expecting a 0-180 deg scan (although the first and > last angles might not be 0 and 180 due to sampling), lower/upper integration > limit would be 0 and 180 deg? > > And why is the division 2 needed there? > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > weighting is "nextAngle - previousAngle" for a certain projection. > In this case I would expect Gap_first to be > > Gap_first = second_angle - lower_integration_limit > (As the lower integration limit is kind of like the "virtual angle" > preceding the first angle?) > > Thanks for your help :) > > Cheers, > Andy > > >> >> Date: Fri, 24 Oct 2014 17:21:27 +0200 >> From: Jan Hoskovec >> To: Andy Shieh >> Cc: "rtk-users at public.kitware.com" >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in >> rtkParkerShortScanImageFilter.txt >> Message-ID: >> >> >> Content-Type: text/plain; charset=UTF-8 >> >> Hi Andy, >> >> I was recently dealing with a similar problem in a different context >> (180? backprojection with irregular sampling and how to handle the >> first and last gaps) and what worked for me was >> >> Gap_first = (second angle - first angle) / 2 - lower integration limit >> >> and, analogically, >> >> Gap_last = upper integration limit - (last angle - second last angle) / 2 >> >> with the integration limits being arbitrary set where I wanted them. >> The idea behind this was that a continuous projection value we are >> miming in the discrete integral should always be represented by the >> closest projection we have, with a known angular segment to cover. >> >> However, that was a DBP-type algorithm, for which the exact >> integration limits are extremely important, it may be different in the >> context of a short scan. But just in case you might find this >> useful... >> >> Cheers, >> >> Jan > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > From hsieandy at gmail.com Mon Oct 27 18:09:05 2014 From: hsieandy at gmail.com (Andy Shieh) Date: Tue, 28 Oct 2014 09:09:05 +1100 Subject: [Rtk-users] Rtk-users Digest, Vol 26, Issue 5 In-Reply-To: References: Message-ID: Hi Jan and Simon, Your suggestions and comments are very inspiring and helpful. Thank you for your help :) Cheers, Andy 2014-10-28 0:34 GMT+11:00 Jan Hoskovec : > Hi Andy, > > I'm sorry not to have replied earlier. For the precisions you wanted, > > 1) your intuition is right, the upper and lower integration limits are > the values you are "expecting", the values delimiting the angular > range you want to cover (whatever is the actual sampling). > > 2) The division by two is there because in my approach, the "zone of > influence" of each sampled projections begins and ends halfway between > the sampled value of the gantry angle and the next / preceding sample. > The weights of other than first and last samples simplify to " (next > angle - previous angle) / 2" for me. > > Hope this would help (unless, of course, you've found a better option > during the weekend :-) ). > > Cheers, > > Jan > > 2014-10-25 15:41 GMT+02:00 Andy Shieh : > > Hi Jan, > > > > Thanks for sharing. > > This does seem useful to me, but I'm not sure if I understand your method > > correctly. > > > > For your lower and upper integration limit, do you mean the limit values > for > > the angular range that you are "expecting"? > > For example if you are expecting a 0-180 deg scan (although the first and > > last angles might not be 0 and 180 due to sampling), lower/upper > integration > > limit would be 0 and 180 deg? > > > > And why is the division 2 needed there? > > I thought in rtkFDKWeightProjectionFilter.txx, the gap value used for the > > weighting is "nextAngle - previousAngle" for a certain projection. > > In this case I would expect Gap_first to be > > > > Gap_first = second_angle - lower_integration_limit > > (As the lower integration limit is kind of like the "virtual angle" > > preceding the first angle?) > > > > Thanks for your help :) > > > > Cheers, > > Andy > > > > > >> > >> Date: Fri, 24 Oct 2014 17:21:27 +0200 > >> From: Jan Hoskovec > >> To: Andy Shieh > >> Cc: "rtk-users at public.kitware.com" > >> Subject: Re: [Rtk-users] itFirstAngle and itLastAngle in > >> rtkParkerShortScanImageFilter.txt > >> Message-ID: > >> > >> > >> Content-Type: text/plain; charset=UTF-8 > >> > >> Hi Andy, > >> > >> I was recently dealing with a similar problem in a different context > >> (180? backprojection with irregular sampling and how to handle the > >> first and last gaps) and what worked for me was > >> > >> Gap_first = (second angle - first angle) / 2 - lower integration limit > >> > >> and, analogically, > >> > >> Gap_last = upper integration limit - (last angle - second last angle) / > 2 > >> > >> with the integration limits being arbitrary set where I wanted them. > >> The idea behind this was that a continuous projection value we are > >> miming in the discrete integral should always be represented by the > >> closest projection we have, with a known angular segment to cover. > >> > >> However, that was a DBP-type algorithm, for which the exact > >> integration limits are extremely important, it may be different in the > >> context of a short scan. But just in case you might find this > >> useful... > >> > >> Cheers, > >> > >> Jan > > > > > > _______________________________________________ > > Rtk-users 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 gdhugo at vcu.edu Fri Oct 31 16:29:35 2014 From: gdhugo at vcu.edu (Geoff Hugo) Date: Fri, 31 Oct 2014 16:29:35 -0400 Subject: [Rtk-users] Issues using PhaseGatingImageFilter Message-ID: I?m trying to use the PhaseGatingImageFilter class to reconstruct a single breathing phase volume and am running into some problems. I?ve incorporated this class into an application similar to rtkfdk, putting it in the pipeline between ParkerShortScanImageFilter and FDKConeBeamReconstructionFilter. If I run the application trying to select a subset of projections using the method SetGatingWindowCenter, I get a segmentation fault. The fault is occurring due to allocation errors in rtk::BackProjectionImageFilter::GenerateInputRequestedRegion. It appears that since the geometry specific to the selected projections is selected in PhaseGatingImageFilter::GenerateData, there is a disconnect between the geometry size and projection stack size during GenerateInputRequestedRegion in the pipeline (pipeline OutputInformation shows the projection stack size is equal to the size of the selected breathing phase projections, but the geometry size is still the total number of (unsorted) projections). I can workaround this problem by calling PhaseGatingImageFilter->Update(), but I think this will break the streaming functionality? Any easy solutions to this problem that will preserve streaming and let me run the full pipeline with only one Update call? My guess is I will need to move the geometry subselection to PhaseGatingImageFilter::GenerateOutputInformation() then call UpdateOutputInformation in the main application? Thanks, Geoff ------------------------------------ Geoffrey D. Hugo, Ph.D. Associate Professor, Radiation Oncology Director, Medical Physics Graduate Program Virginia Commonwealth University (804) 628 3457 -------------- next part -------------- An HTML attachment was scrubbed... URL: