From simon.rit at creatis.insa-lyon.fr Thu Dec 1 00:59:17 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 1 Dec 2016 06:59:17 +0100 Subject: [Rtk-users] Fwd: Have you encountered this artifact? In-Reply-To: References:

Message-ID: Hi, Thanks a lot! It's been merged after minor modifications but would you have one projection to share for creating a small test? You seemed to be unsure of the offsets sign, I think that a wrong sign would show up on the reconstructions. I would suggest to test it if you have time. Simon On Fri, Nov 25, 2016 at 4:25 PM, Andreas Gravgaard Andersen wrote: > Dear Simon, > > I have created a pull-request with the XIM file reader. > I'm sorry for being late with the promised pull-request (there were a lot of > merge conflicts, so it got postponed). > > I have cleaned it up, but it is still not flawless as mentioned in the > pull-request-message. > I have tried to keep the RTK coding-style by creating it as a modified HND > file reader, but I have only a year of experience with C++, so I apologize > if I've left some ugly code in there.. > > Best regards > Andreas > > > __________________________________ > > Andreas Gravgaard Andersen > > Department of Oncology, > > Aarhus University Hospital > > N?rrebrogade 44, > > 8000, Aarhus C > > Mail: andreasg at phys.au.dk > > Cell: +45 3165 8140 > > > > 2016-11-23 18:44 GMT+01:00 Simon Rit : >> >> Dear Andreas, >> Today we had the RTK training and some users were looking for a XIM file >> reader. I pointed to your contributions but any chance to have it put in RTK >> soon? >> Thanks in advance, >> Simon >> >> On Mon, Sep 19, 2016 at 9:26 AM, Simon Rit >> wrote: >>> >>> Hi, >>> Thanks for sharing. There still seems to be some streak artefacts, do you >>> see the same in the Varian reconstruction? >>> I'm looking forward to the pull-request, I think we should try to make >>> the bzip2 optional. >>> Simon >>> >>> On Fri, Sep 16, 2016 at 10:37 PM, Andreas Gravgaard Andersen >>> wrote: >>>> >>>> Thanks for the fast response Simon! >>>> >>>> I flipped the angles (360 - angle[deg]) and it worked! Thanks, you were >>>> right all along! >>>> I just didn't get why it makes a difference. I think I do now, as the >>>> resulting image was flipped upside down and not left/right as I expected. >>>> [attached] >>>> >>>> The reconstruction is significantly better, I'll look into what should >>>> be included in the reader and what I should keep in my program to keep >>>> conformity with the other readers. Then I'll create a pull request. >>>> >>>> Just for the purpose of others hitting the same or a similar bug, I also >>>> attempted: >>>> I did the SART reconstruction with 10 iterations, lambda=0.3, and >>>> Joseph back/forward projection, but with no significant improvement >>>> [attached] >>>> >>>> And: >>>> If you want you can download the data set from: [Dropbox link to 460MB >>>> zip (I'll keep it up as long as Dropbox allows me)] Only the >>>> Acquisitions/subfolder is used along with the Scan.xml (Calibrations folder >>>> may be used in the future in my program, but I'm not sure if you can rely on >>>> the existence of the content). >>>> >>>> A MatLab XimReader is available: link (also available from Varian >>>> bitbucket along a with a python version and a C#->matlab plugin). Otherwise >>>> my fork with the RTK-style reader is available from the same repository (I >>>> have also added Hnc support, thanks to the Geoff Hugo fork, so bzip2 is a >>>> new dependancy). >>>> >>>> Best regards >>>> Andreas >>>> >>>> >>>> __________________________________ >>>> >>>> Andreas Gravgaard Andersen >>>> >>>> Department of Oncology, >>>> >>>> Aarhus University Hospital >>>> >>>> N?rrebrogade 44, >>>> >>>> 8000, Aarhus C >>>> >>>> Mail: andreasg at phys.au.dk >>>> >>>> Cell: +45 3165 8140 >>>> >>>> >>>> >>>> 2016-09-16 16:13 GMT+02:00 Simon Rit : >>>>> >>>>> Hi, >>>>> You can try any iterative reconstruction, they can also handle short >>>>> scans. Start with a few iterations of rtksart or rtkconjugategradient. >>>>> However, the nature of the artifacts indicate more a problem in the geometry >>>>> in my opinion. I have seen such errors when, for example, rotating in the >>>>> wrong direction. I can have a look if you share the dataset. >>>>> Cheers, >>>>> Simon >>>>> >>>>> On Fri, Sep 16, 2016 at 2:56 PM, Andreas Gravgaard Andersen >>>>> wrote: >>>>>> >>>>>> Thanks for the suggestions, Simon and Cyril! >>>>>> >>>>>> I have been carefully looking though the geometry and from what I >>>>>> understand of the transformations matrices, the geometry looks correct/(as >>>>>> expected). >>>>>> >>>>>> HOWEVER: I found out that the reason for the Hnd to behave differently >>>>>> were because had used half-fan scans (full-arc). >>>>>> When I used a full-fan (half-arc) scan of Hnd projections the same >>>>>> artifacts occurs! >>>>>> >>>>>> Are there other (built-in) means of improving half-arc scans, than the >>>>>> parker short scan filter? >>>>>> >>>>>> Parker short scan does a decent job, but the result is still far from >>>>>> the quality of the Varian software reconstruction at least for the CatPhan. >>>>>> >>>>>> Best regards >>>>>> Andreas >>>>>> >>>>>> >>>>>> __________________________________ >>>>>> >>>>>> Andreas Gravgaard Andersen >>>>>> >>>>>> Department of Oncology, >>>>>> >>>>>> Aarhus University Hospital >>>>>> >>>>>> N?rrebrogade 44, >>>>>> >>>>>> 8000, Aarhus C >>>>>> >>>>>> Mail: andreasg at phys.au.dk >>>>>> >>>>>> Cell: +45 3165 8140 >>>>>> >>>>>> >>>>>> >>>>>> 2016-09-14 9:10 GMT+02:00 Cyril Mory >>>>>> : >>>>>>> >>>>>>> One suggestion since it works with the Hnd projections: >>>>>>> You can run rtkprojections twice (with the Hnd projections, then with >>>>>>> Xim projections) and output two projection stack files and two geometry >>>>>>> files, then compare the projection stack files by subtracting one to the >>>>>>> other (with SimpleRTK or clitk) and the geometry files with diff. If they >>>>>>> are identical, then I do not see any reason why the reconstructions should >>>>>>> be different, so my guess is that you will find differences. >>>>>>> >>>>>>> >>>>>>> On 09/13/2016 10:18 PM, Simon Rit wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> I have almost never worked with Varian data but it looks like a >>>>>>>> geometry problem. Maybe the problem comes from a bad ordering of the >>>>>>>> projections which results in assigning a bad geometry to each >>>>>>>> projection. How did you name your projections? Maybe check that the >>>>>>>> order matches that of the RTK geometry file. Otherwise, there might >>>>>>>> be >>>>>>>> an issue in the creation of the geometry file itself. >>>>>>>> All this sounds good, happy bug hunt and don't hesitate to share >>>>>>>> your >>>>>>>> code when you feel it's ready. >>>>>>>> Simon >>>>>>>> >>>>>>>> On Tue, Sep 13, 2016 at 7:06 PM, Andreas Gravgaard Andersen >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Dear RTK experts, >>>>>>>>> >>>>>>>>> I am reconstructing Varian ProBeam projections of the Xim image >>>>>>>>> format. I >>>>>>>>> have written the reader myself - very similar to the Hnd one >>>>>>>>> already >>>>>>>>> available with RTK. >>>>>>>>> Links to my fork: [XimReader, XMLReader, GeometryReader] >>>>>>>>> >>>>>>>>> The reader apparently works (Images and angles displays as expected >>>>>>>>> in UI), >>>>>>>>> however when reconstructing with a regular FDK I get a >>>>>>>>> reconstructed image >>>>>>>>> that is smeared out around the high and low density areas [see >>>>>>>>> attached >>>>>>>>> image] >>>>>>>>> >>>>>>>>> I'm using half arc, full fan images with no bow-tie filter from >>>>>>>>> Scripps >>>>>>>>> (~520 projections). Fixed detector and source (offset=0) with >>>>>>>>> SID=2m, >>>>>>>>> SDD=3m. >>>>>>>>> >>>>>>>>> For the Hnd projections the reconstruction works perfectly (Same >>>>>>>>> algorithm). >>>>>>>>> The reconstruction of the Xim projections performed on Varian >>>>>>>>> software works >>>>>>>>> perfectly. >>>>>>>>> >>>>>>>>> Without the Parker Short Scan Filter the first and last projections >>>>>>>>> creates >>>>>>>>> streaks across the reconstruction as if they were way too bright. >>>>>>>>> If the first few projections are excluded, the following projection >>>>>>>>> will act >>>>>>>>> the same way. >>>>>>>>> >>>>>>>>> The projections are corrected for beam hardening and all the >>>>>>>>> projections >>>>>>>>> have the expected attenuation. >>>>>>>>> No "smearing" filters (like median) is used, and iterative >>>>>>>>> reconstruction >>>>>>>>> makes the same artifacts. >>>>>>>>> >>>>>>>>> Setting the value of the first and last projection to zero has the >>>>>>>>> same >>>>>>>>> effect as excluding. Changing the ramp filter only changes noise, >>>>>>>>> not the >>>>>>>>> artifacts. >>>>>>>>> >>>>>>>>> Have any of you had a similar problem? Am I missing something? >>>>>>>>> Any suggestions are welcome I'm running out of ideas. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Andreas >>>>>>>>> >>>>>>>>> __________________________________ >>>>>>>>> >>>>>>>>> Andreas Gravgaard Andersen >>>>>>>>> >>>>>>>>> Department of Oncology, >>>>>>>>> >>>>>>>>> Aarhus University Hospital >>>>>>>>> >>>>>>>>> N?rrebrogade 44, >>>>>>>>> >>>>>>>>> 8000, Aarhus C >>>>>>>>> >>>>>>>>> Mail: andreasg at phys.au.dk >>>>>>>>> >>>>>>>>> Cell: +45 3165 8140 >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 shiraska at gmail.com Fri Dec 2 04:50:28 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Fri, 2 Dec 2016 10:50:28 +0100 Subject: [Rtk-users] Curved detector Message-ID: Hi Simon, I am using the latest version of RTK, downloaded from Git. How can I reconstruct the projection data from curved detector? Regarding geometry, do I need to specify additional parameters other than the current nine parameters? Is it also possible to forward project the volume to a curved detector? With regards, Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Fri Dec 2 08:48:04 2016 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 2 Dec 2016 14:48:04 +0100 Subject: [Rtk-users] Curved detector In-Reply-To: References: Message-ID: <64500db0-832a-b0bd-e002-554e3e68d67c@creatis.insa-lyon.fr> Hi Shiras, First, you need to checkout and compile the "rayBasedIterator" branch. Then, your geometry file must only contain some value and it will automatically be handled correctly. However, not all forward and back projectors have been modified to handle the curved detector geometry, and only iterative reconstruction methods will work (FDK with a curved detector hasn't been implemented yet). So you can use: - rtksart - rtkconjugategradient - rtkregularizedconjugategradient - rtkadmmtotalvariation - rtkadmmwavelets and you need to set the forward projection operator ("--fp" option) to either Joseph or CudaRayCast, and the back projection operator ("--bp" option) to Joseph. We plan to update the existing forward and back projectors so that as many as possible can handle both flat and curved detectors, but at the moment only this limited list will work. Regards, Cyril On 12/02/2016 10:50 AM, Shiras Abdurahman wrote: > Hi Simon, > > I am using the latest version of RTK, downloaded from Git. How can I > reconstruct the projection data from curved detector? Regarding > geometry, do I need to specify additional parameters other than the > current nine parameters? Is it also possible to forward project the > volume to a curved detector? > > With regards, > Shiras > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Dec 5 02:07:36 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 5 Dec 2016 08:07:36 +0100 Subject: [Rtk-users] Curved detector In-Reply-To: <64500db0-832a-b0bd-e002-554e3e68d67c@creatis.insa-lyon.fr> References: <64500db0-832a-b0bd-e002-554e3e68d67c@creatis.insa-lyon.fr> Message-ID: Beaucoup mieux je pense. - page 1 : recalage non-rigide 3D/3D ? Tu veux dire 2D/3D ? - page 1 : m?me une estimation de mouvement imparfaite -> une estimation de mouvement m?me imparfaite - page 2 : ce que tu d?cris au niveau workflow clinique est pour un d?partement de RT avanc?, pas le traitement par d?faut. Tu peux laisser comme ?a, rajoute juste peut ?tre une pr?cision de cet ordre. - page 2 : ? mon avis la r?f 10 permet une estimation fid?le du mouvement et une recon sans art?fact. Mais ?a n'est appliqu? (juste une coupe simul?e dans la r?f dans mon souvenir). - page 3 : pour les donn?es, il y a aussi des consid?rations ?thiques (consentement patient) Je ne sais pas s'il ne faut pas aussi mentionner les liens dans TIMC sur chaque item, tout en gardant un paragraphe s?par?. En gros, ?a prend la bonne voie mais il faut ?toffer, par exemple en faisant circuler. Peut-?tre en se lan?ant dans de nouveaux sujets pour toi. Je te joins les deux projets qu'on a soumis avec Rolf et Laurent, ? mon avis tu peux faire un paragraphe sur chacun en plus si ?a te plait. A+, Simon On Fri, Dec 2, 2016 at 2:48 PM, Cyril Mory wrote: > Hi Shiras, > > First, you need to checkout and compile the "rayBasedIterator" branch. > > Then, your geometry file must only contain > > > some value > > > and it will automatically be handled correctly. > > However, not all forward and back projectors have been modified to handle > the curved detector geometry, and only iterative reconstruction methods will > work (FDK with a curved detector hasn't been implemented yet). > So you can use: > - rtksart > - rtkconjugategradient > - rtkregularizedconjugategradient > - rtkadmmtotalvariation > - rtkadmmwavelets > and you need to set the forward projection operator ("--fp" option) to > either Joseph or CudaRayCast, and the back projection operator ("--bp" > option) to Joseph. > > We plan to update the existing forward and back projectors so that as many > as possible can handle both flat and curved detectors, but at the moment > only this limited list will work. > > Regards, > Cyril > > > On 12/02/2016 10:50 AM, Shiras Abdurahman wrote: > > Hi Simon, > > I am using the latest version of RTK, downloaded from Git. How can I > reconstruct the projection data from curved detector? Regarding geometry, do > I need to specify additional parameters other than the current nine > parameters? Is it also possible to forward project the volume to a curved > detector? > > With regards, > Shiras > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users > > -------------- next part -------------- A non-text attachment was scrubbed... Name: ROIdore-Appendix-ANR2017.pdf Type: application/pdf Size: 23175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ROIdore-ANR2017.pdf Type: application/pdf Size: 77508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: X-Range-Appendix.ANR2017.pdf Type: application/pdf Size: 29004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: X-Range.ANR2017.pdf Type: application/pdf Size: 31466 bytes Desc: not available URL: From simon.rit at creatis.insa-lyon.fr Mon Dec 5 02:39:19 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Mon, 5 Dec 2016 08:39:19 +0100 Subject: [Rtk-users] Curved detector In-Reply-To: References: <64500db0-832a-b0bd-e002-554e3e68d67c@creatis.insa-lyon.fr> Message-ID: Dear all, Apologies, this email has been sent by mistake to the RTK mailing list. Please ignore and delete it. Thanks, Simon On Mon, Dec 5, 2016 at 8:07 AM, Simon Rit wrote: > Beaucoup mieux je pense. > - page 1 : recalage non-rigide 3D/3D ? Tu veux dire 2D/3D ? > - page 1 : m?me une estimation de mouvement imparfaite -> une > estimation de mouvement m?me imparfaite > - page 2 : ce que tu d?cris au niveau workflow clinique est pour un > d?partement de RT avanc?, pas le traitement par d?faut. Tu peux > laisser comme ?a, rajoute juste peut ?tre une pr?cision de cet ordre. > - page 2 : ? mon avis la r?f 10 permet une estimation fid?le du > mouvement et une recon sans art?fact. Mais ?a n'est appliqu? (juste > une coupe simul?e dans la r?f dans mon souvenir). > - page 3 : pour les donn?es, il y a aussi des consid?rations ?thiques > (consentement patient) > > Je ne sais pas s'il ne faut pas aussi mentionner les liens dans TIMC > sur chaque item, tout en gardant un paragraphe s?par?. > En gros, ?a prend la bonne voie mais il faut ?toffer, par exemple en > faisant circuler. Peut-?tre en se lan?ant dans de nouveaux sujets pour > toi. Je te joins les deux projets qu'on a soumis avec Rolf et Laurent, > ? mon avis tu peux faire un paragraphe sur chacun en plus si ?a te > plait. > A+, > Simon > > On Fri, Dec 2, 2016 at 2:48 PM, Cyril Mory > wrote: >> Hi Shiras, >> >> First, you need to checkout and compile the "rayBasedIterator" branch. >> >> Then, your geometry file must only contain >> >> >> some value >> >> >> and it will automatically be handled correctly. >> >> However, not all forward and back projectors have been modified to handle >> the curved detector geometry, and only iterative reconstruction methods will >> work (FDK with a curved detector hasn't been implemented yet). >> So you can use: >> - rtksart >> - rtkconjugategradient >> - rtkregularizedconjugategradient >> - rtkadmmtotalvariation >> - rtkadmmwavelets >> and you need to set the forward projection operator ("--fp" option) to >> either Joseph or CudaRayCast, and the back projection operator ("--bp" >> option) to Joseph. >> >> We plan to update the existing forward and back projectors so that as many >> as possible can handle both flat and curved detectors, but at the moment >> only this limited list will work. >> >> Regards, >> Cyril >> >> >> On 12/02/2016 10:50 AM, Shiras Abdurahman wrote: >> >> Hi Simon, >> >> I am using the latest version of RTK, downloaded from Git. How can I >> reconstruct the projection data from curved detector? Regarding geometry, do >> I need to specify additional parameters other than the current nine >> parameters? Is it also possible to forward project the volume to a curved >> detector? >> >> With regards, >> Shiras >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> From wuchao04 at gmail.com Thu Dec 15 06:15:51 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 15 Dec 2016 12:15:51 +0100 Subject: [Rtk-users] Type of CudaDataManager::m_BufferSize Message-ID: Hi all, In utilities\ITKCudaCommon\include\itkCudaDataManager.h the type of CudaDataManager::m_BufferSize is unsigned int, which prevents buffering >4GB image data in CUDA memory. In the same file, the type of GPUMemPointer::m_BufferSize is size_t which looks more proper. Is there any special reason for this unsigned int type? I am going to change the type from unsigned int to size_t and test what will happen, but if anyone already have the experience please let me know. Many thanks. Best regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Dec 22 08:46:34 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 22 Dec 2016 14:46:34 +0100 Subject: [Rtk-users] New position at IBA Message-ID: Hi, IBA, a member of our consortium, opens a position on CBCT imaging: http://www.iba-careers.com/?page=job&job_id=11878&lang=en If you are looking for a job and if you want to continue using RTK, that's a good opportunity. Kind regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Dec 1 00:59:17 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 1 Dec 2016 06:59:17 +0100 Subject: [Rtk-users] Fwd: Have you encountered this artifact? In-Reply-To: References:

Message-ID: Hi, Thanks a lot! It's been merged after minor modifications but would you have one projection to share for creating a small test? You seemed to be unsure of the offsets sign, I think that a wrong sign would show up on the reconstructions. I would suggest to test it if you have time. Simon On Fri, Nov 25, 2016 at 4:25 PM, Andreas Gravgaard Andersen wrote: > Dear Simon, > > I have created a pull-request with the XIM file reader. > I'm sorry for being late with the promised pull-request (there were a lot of > merge conflicts, so it got postponed). > > I have cleaned it up, but it is still not flawless as mentioned in the > pull-request-message. > I have tried to keep the RTK coding-style by creating it as a modified HND > file reader, but I have only a year of experience with C++, so I apologize > if I've left some ugly code in there.. > > Best regards > Andreas > > > __________________________________ > > Andreas Gravgaard Andersen > > Department of Oncology, > > Aarhus University Hospital > > N?rrebrogade 44, > > 8000, Aarhus C > > Mail: andreasg at phys.au.dk > > Cell: +45 3165 8140 > > > > 2016-11-23 18:44 GMT+01:00 Simon Rit : >> >> Dear Andreas, >> Today we had the RTK training and some users were looking for a XIM file >> reader. I pointed to your contributions but any chance to have it put in RTK >> soon? >> Thanks in advance, >> Simon >> >> On Mon, Sep 19, 2016 at 9:26 AM, Simon Rit >> wrote: >>> >>> Hi, >>> Thanks for sharing. There still seems to be some streak artefacts, do you >>> see the same in the Varian reconstruction? >>> I'm looking forward to the pull-request, I think we should try to make >>> the bzip2 optional. >>> Simon >>> >>> On Fri, Sep 16, 2016 at 10:37 PM, Andreas Gravgaard Andersen >>> wrote: >>>> >>>> Thanks for the fast response Simon! >>>> >>>> I flipped the angles (360 - angle[deg]) and it worked! Thanks, you were >>>> right all along! >>>> I just didn't get why it makes a difference. I think I do now, as the >>>> resulting image was flipped upside down and not left/right as I expected. >>>> [attached] >>>> >>>> The reconstruction is significantly better, I'll look into what should >>>> be included in the reader and what I should keep in my program to keep >>>> conformity with the other readers. Then I'll create a pull request. >>>> >>>> Just for the purpose of others hitting the same or a similar bug, I also >>>> attempted: >>>> I did the SART reconstruction with 10 iterations, lambda=0.3, and >>>> Joseph back/forward projection, but with no significant improvement >>>> [attached] >>>> >>>> And: >>>> If you want you can download the data set from: [Dropbox link to 460MB >>>> zip (I'll keep it up as long as Dropbox allows me)] Only the >>>> Acquisitions/subfolder is used along with the Scan.xml (Calibrations folder >>>> may be used in the future in my program, but I'm not sure if you can rely on >>>> the existence of the content). >>>> >>>> A MatLab XimReader is available: link (also available from Varian >>>> bitbucket along a with a python version and a C#->matlab plugin). Otherwise >>>> my fork with the RTK-style reader is available from the same repository (I >>>> have also added Hnc support, thanks to the Geoff Hugo fork, so bzip2 is a >>>> new dependancy). >>>> >>>> Best regards >>>> Andreas >>>> >>>> >>>> __________________________________ >>>> >>>> Andreas Gravgaard Andersen >>>> >>>> Department of Oncology, >>>> >>>> Aarhus University Hospital >>>> >>>> N?rrebrogade 44, >>>> >>>> 8000, Aarhus C >>>> >>>> Mail: andreasg at phys.au.dk >>>> >>>> Cell: +45 3165 8140 >>>> >>>> >>>> >>>> 2016-09-16 16:13 GMT+02:00 Simon Rit : >>>>> >>>>> Hi, >>>>> You can try any iterative reconstruction, they can also handle short >>>>> scans. Start with a few iterations of rtksart or rtkconjugategradient. >>>>> However, the nature of the artifacts indicate more a problem in the geometry >>>>> in my opinion. I have seen such errors when, for example, rotating in the >>>>> wrong direction. I can have a look if you share the dataset. >>>>> Cheers, >>>>> Simon >>>>> >>>>> On Fri, Sep 16, 2016 at 2:56 PM, Andreas Gravgaard Andersen >>>>> wrote: >>>>>> >>>>>> Thanks for the suggestions, Simon and Cyril! >>>>>> >>>>>> I have been carefully looking though the geometry and from what I >>>>>> understand of the transformations matrices, the geometry looks correct/(as >>>>>> expected). >>>>>> >>>>>> HOWEVER: I found out that the reason for the Hnd to behave differently >>>>>> were because had used half-fan scans (full-arc). >>>>>> When I used a full-fan (half-arc) scan of Hnd projections the same >>>>>> artifacts occurs! >>>>>> >>>>>> Are there other (built-in) means of improving half-arc scans, than the >>>>>> parker short scan filter? >>>>>> >>>>>> Parker short scan does a decent job, but the result is still far from >>>>>> the quality of the Varian software reconstruction at least for the CatPhan. >>>>>> >>>>>> Best regards >>>>>> Andreas >>>>>> >>>>>> >>>>>> __________________________________ >>>>>> >>>>>> Andreas Gravgaard Andersen >>>>>> >>>>>> Department of Oncology, >>>>>> >>>>>> Aarhus University Hospital >>>>>> >>>>>> N?rrebrogade 44, >>>>>> >>>>>> 8000, Aarhus C >>>>>> >>>>>> Mail: andreasg at phys.au.dk >>>>>> >>>>>> Cell: +45 3165 8140 >>>>>> >>>>>> >>>>>> >>>>>> 2016-09-14 9:10 GMT+02:00 Cyril Mory >>>>>> : >>>>>>> >>>>>>> One suggestion since it works with the Hnd projections: >>>>>>> You can run rtkprojections twice (with the Hnd projections, then with >>>>>>> Xim projections) and output two projection stack files and two geometry >>>>>>> files, then compare the projection stack files by subtracting one to the >>>>>>> other (with SimpleRTK or clitk) and the geometry files with diff. If they >>>>>>> are identical, then I do not see any reason why the reconstructions should >>>>>>> be different, so my guess is that you will find differences. >>>>>>> >>>>>>> >>>>>>> On 09/13/2016 10:18 PM, Simon Rit wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> I have almost never worked with Varian data but it looks like a >>>>>>>> geometry problem. Maybe the problem comes from a bad ordering of the >>>>>>>> projections which results in assigning a bad geometry to each >>>>>>>> projection. How did you name your projections? Maybe check that the >>>>>>>> order matches that of the RTK geometry file. Otherwise, there might >>>>>>>> be >>>>>>>> an issue in the creation of the geometry file itself. >>>>>>>> All this sounds good, happy bug hunt and don't hesitate to share >>>>>>>> your >>>>>>>> code when you feel it's ready. >>>>>>>> Simon >>>>>>>> >>>>>>>> On Tue, Sep 13, 2016 at 7:06 PM, Andreas Gravgaard Andersen >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Dear RTK experts, >>>>>>>>> >>>>>>>>> I am reconstructing Varian ProBeam projections of the Xim image >>>>>>>>> format. I >>>>>>>>> have written the reader myself - very similar to the Hnd one >>>>>>>>> already >>>>>>>>> available with RTK. >>>>>>>>> Links to my fork: [XimReader, XMLReader, GeometryReader] >>>>>>>>> >>>>>>>>> The reader apparently works (Images and angles displays as expected >>>>>>>>> in UI), >>>>>>>>> however when reconstructing with a regular FDK I get a >>>>>>>>> reconstructed image >>>>>>>>> that is smeared out around the high and low density areas [see >>>>>>>>> attached >>>>>>>>> image] >>>>>>>>> >>>>>>>>> I'm using half arc, full fan images with no bow-tie filter from >>>>>>>>> Scripps >>>>>>>>> (~520 projections). Fixed detector and source (offset=0) with >>>>>>>>> SID=2m, >>>>>>>>> SDD=3m. >>>>>>>>> >>>>>>>>> For the Hnd projections the reconstruction works perfectly (Same >>>>>>>>> algorithm). >>>>>>>>> The reconstruction of the Xim projections performed on Varian >>>>>>>>> software works >>>>>>>>> perfectly. >>>>>>>>> >>>>>>>>> Without the Parker Short Scan Filter the first and last projections >>>>>>>>> creates >>>>>>>>> streaks across the reconstruction as if they were way too bright. >>>>>>>>> If the first few projections are excluded, the following projection >>>>>>>>> will act >>>>>>>>> the same way. >>>>>>>>> >>>>>>>>> The projections are corrected for beam hardening and all the >>>>>>>>> projections >>>>>>>>> have the expected attenuation. >>>>>>>>> No "smearing" filters (like median) is used, and iterative >>>>>>>>> reconstruction >>>>>>>>> makes the same artifacts. >>>>>>>>> >>>>>>>>> Setting the value of the first and last projection to zero has the >>>>>>>>> same >>>>>>>>> effect as excluding. Changing the ramp filter only changes noise, >>>>>>>>> not the >>>>>>>>> artifacts. >>>>>>>>> >>>>>>>>> Have any of you had a similar problem? Am I missing something? >>>>>>>>> Any suggestions are welcome I'm running out of ideas. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Andreas >>>>>>>>> >>>>>>>>> __________________________________ >>>>>>>>> >>>>>>>>> Andreas Gravgaard Andersen >>>>>>>>> >>>>>>>>> Department of Oncology, >>>>>>>>> >>>>>>>>> Aarhus University Hospital >>>>>>>>> >>>>>>>>> N?rrebrogade 44, >>>>>>>>> >>>>>>>>> 8000, Aarhus C >>>>>>>>> >>>>>>>>> Mail: andreasg at phys.au.dk >>>>>>>>> >>>>>>>>> Cell: +45 3165 8140 >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 shiraska at gmail.com Fri Dec 2 04:50:28 2016 From: shiraska at gmail.com (Shiras Abdurahman) Date: Fri, 2 Dec 2016 10:50:28 +0100 Subject: [Rtk-users] Curved detector Message-ID: Hi Simon, I am using the latest version of RTK, downloaded from Git. How can I reconstruct the projection data from curved detector? Regarding geometry, do I need to specify additional parameters other than the current nine parameters? Is it also possible to forward project the volume to a curved detector? With regards, Shiras -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.mory at creatis.insa-lyon.fr Fri Dec 2 08:48:04 2016 From: cyril.mory at creatis.insa-lyon.fr (Cyril Mory) Date: Fri, 2 Dec 2016 14:48:04 +0100 Subject: [Rtk-users] Curved detector In-Reply-To: References: Message-ID: <64500db0-832a-b0bd-e002-554e3e68d67c@creatis.insa-lyon.fr> Hi Shiras, First, you need to checkout and compile the "rayBasedIterator" branch. Then, your geometry file must only contain some value and it will automatically be handled correctly. However, not all forward and back projectors have been modified to handle the curved detector geometry, and only iterative reconstruction methods will work (FDK with a curved detector hasn't been implemented yet). So you can use: - rtksart - rtkconjugategradient - rtkregularizedconjugategradient - rtkadmmtotalvariation - rtkadmmwavelets and you need to set the forward projection operator ("--fp" option) to either Joseph or CudaRayCast, and the back projection operator ("--bp" option) to Joseph. We plan to update the existing forward and back projectors so that as many as possible can handle both flat and curved detectors, but at the moment only this limited list will work. Regards, Cyril On 12/02/2016 10:50 AM, Shiras Abdurahman wrote: > Hi Simon, > > I am using the latest version of RTK, downloaded from Git. How can I > reconstruct the projection data from curved detector? Regarding > geometry, do I need to specify additional parameters other than the > current nine parameters? Is it also possible to forward project the > volume to a curved detector? > > With regards, > Shiras > > > _______________________________________________ > Rtk-users mailing list > Rtk-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/rtk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Mon Dec 5 02:07:36 2016 From: simon.rit at creatis.insa-lyon.fr (simon.rit at creatis.insa-lyon.fr) Date: Mon, 5 Dec 2016 08:07:36 +0100 Subject: [Rtk-users] Curved detector In-Reply-To: <64500db0-832a-b0bd-e002-554e3e68d67c@creatis.insa-lyon.fr> References: <64500db0-832a-b0bd-e002-554e3e68d67c@creatis.insa-lyon.fr> Message-ID: (removed) From simon.rit at creatis.insa-lyon.fr Mon Dec 5 02:39:19 2016 From: simon.rit at creatis.insa-lyon.fr (simon.rit at creatis.insa-lyon.fr) Date: Mon, 5 Dec 2016 08:39:19 +0100 Subject: [Rtk-users] Curved detector In-Reply-To: References: <64500db0-832a-b0bd-e002-554e3e68d67c@creatis.insa-lyon.fr> Message-ID: (removed) On Mon, Dec 5, 2016 at 8:07 AM, Simon Rit wrote: > Beaucoup mieux je pense. > - page 1 : recalage non-rigide 3D/3D ? Tu veux dire 2D/3D ? > - page 1 : m?me une estimation de mouvement imparfaite -> une > estimation de mouvement m?me imparfaite > - page 2 : ce que tu d?cris au niveau workflow clinique est pour un > d?partement de RT avanc?, pas le traitement par d?faut. Tu peux > laisser comme ?a, rajoute juste peut ?tre une pr?cision de cet ordre. > - page 2 : ? mon avis la r?f 10 permet une estimation fid?le du > mouvement et une recon sans art?fact. Mais ?a n'est appliqu? (juste > une coupe simul?e dans la r?f dans mon souvenir). > - page 3 : pour les donn?es, il y a aussi des consid?rations ?thiques > (consentement patient) > > Je ne sais pas s'il ne faut pas aussi mentionner les liens dans TIMC > sur chaque item, tout en gardant un paragraphe s?par?. > En gros, ?a prend la bonne voie mais il faut ?toffer, par exemple en > faisant circuler. Peut-?tre en se lan?ant dans de nouveaux sujets pour > toi. Je te joins les deux projets qu'on a soumis avec Rolf et Laurent, > ? mon avis tu peux faire un paragraphe sur chacun en plus si ?a te > plait. > A+, > Simon > > On Fri, Dec 2, 2016 at 2:48 PM, Cyril Mory > wrote: >> Hi Shiras, >> >> First, you need to checkout and compile the "rayBasedIterator" branch. >> >> Then, your geometry file must only contain >> >> >> some value >> >> >> and it will automatically be handled correctly. >> >> However, not all forward and back projectors have been modified to handle >> the curved detector geometry, and only iterative reconstruction methods will >> work (FDK with a curved detector hasn't been implemented yet). >> So you can use: >> - rtksart >> - rtkconjugategradient >> - rtkregularizedconjugategradient >> - rtkadmmtotalvariation >> - rtkadmmwavelets >> and you need to set the forward projection operator ("--fp" option) to >> either Joseph or CudaRayCast, and the back projection operator ("--bp" >> option) to Joseph. >> >> We plan to update the existing forward and back projectors so that as many >> as possible can handle both flat and curved detectors, but at the moment >> only this limited list will work. >> >> Regards, >> Cyril >> >> >> On 12/02/2016 10:50 AM, Shiras Abdurahman wrote: >> >> Hi Simon, >> >> I am using the latest version of RTK, downloaded from Git. How can I >> reconstruct the projection data from curved detector? Regarding geometry, do >> I need to specify additional parameters other than the current nine >> parameters? Is it also possible to forward project the volume to a curved >> detector? >> >> With regards, >> Shiras >> >> >> _______________________________________________ >> Rtk-users mailing list >> Rtk-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/rtk-users >> >> From wuchao04 at gmail.com Thu Dec 15 06:15:51 2016 From: wuchao04 at gmail.com (Chao Wu) Date: Thu, 15 Dec 2016 12:15:51 +0100 Subject: [Rtk-users] Type of CudaDataManager::m_BufferSize Message-ID: Hi all, In utilities\ITKCudaCommon\include\itkCudaDataManager.h the type of CudaDataManager::m_BufferSize is unsigned int, which prevents buffering >4GB image data in CUDA memory. In the same file, the type of GPUMemPointer::m_BufferSize is size_t which looks more proper. Is there any special reason for this unsigned int type? I am going to change the type from unsigned int to size_t and test what will happen, but if anyone already have the experience please let me know. Many thanks. Best regards, Chao -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Dec 22 08:46:34 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 22 Dec 2016 14:46:34 +0100 Subject: [Rtk-users] New position at IBA Message-ID: Hi, IBA, a member of our consortium, opens a position on CBCT imaging: http://www.iba-careers.com/?page=job&job_id=11878&lang=en If you are looking for a job and if you want to continue using RTK, that's a good opportunity. Kind regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.rit at creatis.insa-lyon.fr Thu Dec 1 00:59:17 2016 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 1 Dec 2016 06:59:17 +0100 Subject: [Rtk-users] Fwd: Have you encountered this artifact? In-Reply-To: References: