From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > > From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > > From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > > From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > > From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > > From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > > From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > > From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > > From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > > From simon.rit at creatis.insa-lyon.fr Tue Oct 8 06:26:41 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Tue, 8 Oct 2013 12:26:41 +0200 Subject: [Rtk-users] CBCT projection data for Elekta XVI In-Reply-To: References: Message-ID: Hi Seelan, Please use the mailing list. It's a good question for everyone! I have added some explanations on the wiki http://wiki.openrtk.org/index.php/RTK/Examples/ElektaReconstruction Please let me know if something's unclear. Simon On Tue, Oct 8, 2013 at 11:46 AM, Vythialingam Sathiaseelan wrote: > Hi Simon: > > I am relatively new to CBCT reconstruction software. I am interested in learning and using the RTK software tool kit. > > I am trying to understand how projection data are stored in aN Elekta XVI CBCT scanner. > > I have been searching with Google for info on projection data format and where these are stored in the Elekta XVI computer. I have not been able to find any. > > Will you be able to direct me to this information? I am interested in the data format of the raw projection image data and the directory location of the files. > > Thanks for your help. > > > Sincerely, > > Seelan > > > V. Sathiaseelan, PhD > Department of Radiation Oncology > Feinberg School of Medicine > Northwestern University > Chicago, IL, USA > > > > > > > > > Sent from my iPad From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:41:32 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:41:32 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Hi Uffe, I have committed some changes that should take care of the scatter correction bug https://github.com/SimonRit/RTK/commit/984564ab6d445cf1ff6c625eabca8cc2caba4b7e The scatter to primary ratio is still set to 0 by default. I'll try to find a way to pass such parameters from the command line of rtk applications but in the mean time, you may want to test it. Feedback is appreciated. Thanks again for reporting this, Simon On Sun, Sep 15, 2013 at 10:40 PM, Simon Rit wrote: > Hi Uffe, > I think you're right but I must take the time to look into it > carefully. The algorithm is that of Boellaard, no doubt about it. But > I think I should have split > rtkElektaSynergyRawToAttenuationImageFilter in two and apply it in > betwee. I'll try to fix that asap but I have a very busy week. I'll > keep you posted... > Simon > > On Fri, Sep 13, 2013 at 10:10 AM, Uffe Bernchou wrote: >> >> Dear Simon, >> >> Thank you very much for your reply. It will help me a lot. >> >> I did try to play a little with the BoellaardScatterCorrection. Setting m_ScatterToPrimaryRatio to 0.2 (I have been informed that this is the value used clinically in XVI) gives awful images. I think there might be something generally wrong with the implementation, but I could definitely be incorrect. >> >> The raw .his images from XVI have high values when the beam is blocked and low values when unblocked. As far as I can see, the images in BoellaardScatterCorrectionImageFilter still have this format. If this is true, the code >> >> *** >> for(unsigned int i=0; i> { >> smallestValue = std::min(smallestValue, (double)itInSlice.Get() ); >> if(itInSlice.Get()>=m_AirThreshold) >> { >> averageBehindPatient += itInSlice.Get(); >> } >> ++itInSlice; >> } >> averageBehindPatient /= npixelPerSlice; >> *** >> >> correctly finds the average pixel value behind the patient. Afterwards the scatter correction is calculated: >> >> *** >> // Compute constant correction >> double correction = averageBehindPatient * m_ScatterToPrimaryRatio; >> >> // Apply non-negativity constraint >> if(smallestValue-correction> correction = smallestValue - m_NonNegativityConstraintThreshold; >> *** >> >> However, then the correction is subtracted: >> >> *** >> // Remove constant factor >> for(unsigned int i=0; i> { >> itOut.Set( itIn.Get() - correction ); >> ++itIn; >> ++itOut; >> } >> *** >> >> But as far as I understand, this cannot be right when the images have the format mentioned above. It would add more scatter to the projection instead of subtracting. I think the non-negativity constraint also is fault by the same argument. >> >> Maybe I'm missing something and would be happy to be proven wrong :-) >> >> Best regards, >> Uffe >> >> >> >> -----Oprindelig meddelelse----- >> Fra: simon.rit at gmail.com [mailto:simon.rit at gmail.com] P? vegne af Simon Rit >> Sendt: 13. september 2013 09:32 >> Til: Uffe Bernchou >> Cc: Carsten Brink; Rune Slot Thing; rtk-users at openrtk.org >> Emne: Re: RTK code correction >> >> Hi Uffe, >> Thanks for your email. Please prefer the mailing list for questions of >> general interest, you might get quicker answer! >> It is correct that BoellaardScatterCorrectionImageFilter it not >> activated. But it is in place. So let me try to describe how that >> works: >> - many RTK programs use the filter rtkProjectionsReader.h to read raw >> data and convert them to attenuation. These two steps correspond to >> filters that are scanner dependent. The pointers to these filters are >> stored in m_RawDataReader and m_RawToProjectionsFilter. >> - the raw to attenuation conversion of Elekta Synergy is >> rtkElektaSynergyRawToAttenuationImageFilter.h. This filter is a >> so-called mini-pipeline filter, i.e., a pipeline of filters. One of >> them is the BoellaardScatterCorrection. >> - you should have a look at the implementation of this filter. You >> will notice that you have some parameters to set. One of them is the >> m_ScatterToPrimaryRatio. It speaks for itself I think. Right now, it >> is set to 0 so there is no scatter correction. But you can modify it >> to test the scatter correction. FYI, it was by default set to 0.33 in >> the first versions of XVI (it might have been lowered since because we >> had observed that it was not always ideal but I did not check). There >> is no mechanism to set it from the command line of rtkfdk yet but that >> could quite easily be done. >> Simon >> >> On Wed, Sep 11, 2013 at 8:36 PM, Uffe Bernchou wrote: >>> Dear Simon, >>> >>> >>> >>> I'm still very curious as to whether a simple solution to correct for >>> scatter is attempted in rtkfdk. I can see that the procedure for scatter >>> correction used in XVI is implemented in >>> BoellaardScatterCorrectionImageFilter, but this code does not seem to be >>> used anywhere when running rtkfdk. However, it could just be me getting lost >>> in the code J >>> >>> >>> >>> It would help me a lot if you could inform me as to whether any solution >>> scatter subtraction is done when running rtkfdk. >>> >>> >>> >>> Best Regards >>> >>> Uffe >>> From simon.rit at creatis.insa-lyon.fr Thu Oct 24 17:47:44 2013 From: simon.rit at creatis.insa-lyon.fr (Simon Rit) Date: Thu, 24 Oct 2013 23:47:44 +0200 Subject: [Rtk-users] RTK code correction In-Reply-To: References: Message-ID: Regarding the field of view issue, I have added an option to allow adequate FOV computation with a displaced detector https://github.com/SimonRit/RTK/commit/ae71a4bb33a88af1ceb86f283ac215e6ba095062 This is basically what you have suggested but you have to say explicitely that you use a displaced detector. See https://github.com/SimonRit/RTK/commit/9a12222ae0d4f527b09fcc83513f436070538c4b Simon On Tue, Aug 27, 2013 at 10:59 AM, Uffe Bernchou wrote: > > > Dear Simon, > > > > I?m writing you because I am a user of the nice reconstruction toolkit that > you generously have shared on openrtk.org. Colleagues and I are working on > imaging in radiotherapy, and have been looking for an open source algorithm > for reconstruction of cone beam data from Elekta?s XVI system. > > > > During our work we have discovered a small bug in > rtkFieldOfViewImageFilter.txx. The code works fine with cone beam images > where the detector is in the ?small? position. However, for M scans only a > very small field of view is displayed. The problem seems to be related to > the following lines: > > > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ) ); > > m_Radius = std::min( m_Radius, vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) ) ); > > > > With this code, only the intersection where space imaged during every frame > is in the FOV. When the panel is in other positions than small, this will > created problems. A small hack that changes this code to > > > > m_Radius = std::min( m_Radius, std::max(vcl_abs( > sourceOffsetX+mag*(corner1[0]+projOffsetX-sourceOffsetX) ),vcl_abs( > sourceOffsetX+mag*(corner2[0]+projOffsetX-sourceOffsetX) )) ); > > > > seems to solve the problem. I think you should be aware of this problem, and > consider to change the code in a future update. > > > > > > One of my colleagues (Rune Slot Thing) is working on improving the image > quality of our cone beam images by subtraction of scatter in the projection > images using MC simulations. We are planning to test the results using the > RTK reconstruction code in order to avoid the attempts to subtract scatter > by the XVI software. > > > > Perhaps you would be so kind to inform me on whether any attempts are done > to subtract scatter in your algorithm? > > > > Thanking you in advance. > > > > Best regards, > > Uffe > > > > > > ------------------------------ > > Uffe Bernchou, Ph.d. > > Post doc > > Laboratory of Radiation Physics, OUH > > Institute of Clinical Research, SDU > > Email: uffe.bernchou at rsyd.dk > > Phone: +45 29796478 > > Sdr. Boulevard 29, Indgang 97, 5000 Odense C > > > >