[Rtk-users] RTK code correction

[Uffe Bernchou]

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<npixelPerSlice; 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<m_NonNegativityConstraintThreshold)
   correction = smallestValue - m_NonNegativityConstraintThreshold;
***

However, then the correction is subtracted:

***
// Remove constant factor
for(unsigned int i=0; i<npixelPerSlice; 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 <Uffe.Bernchou at rsyd.dk> 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
>