[Rtk-users] Obtaining HU number from RTK float data after CBCT reconstruction

[Yang K Park]

Hi Rune, 

 

That is a great tip. Thank you so much. (We’ve recently installed XVI5.0 so
I’m better off trying to use that new feature.)

 

My remaining question is, then, when you guys do a  forward projection for
clinical CT images (singed short) using rtk, which pre-processing do you do?

 

I think some “short to float” conversion is needed and that conversion
formula should be also working with FDK to restore the CT image with same HU
values.

 

Thanks.

 

Yang

 

 

 

From: Rune Slot Thing [mailto:Rune.Slot.Thing at rsyd.dk] 
Sent: Tuesday, March 03, 2015 3:29 AM
To: 'Yang K Park'; rtk-users at openrtk.org
Subject: SV: [Rtk-users] Obtaining HU number from RTK float data after CBCT
reconstruction

 

Hi Yang,

 

The short answer to your question is that the projection images you acquire
on an Elekta CBCT unit are not normalized properly. If you perform the same
scan with two different exposures (e.g. double the mAs value), you will get
different projection images and hence different grey values in the
reconstructed images, regardless of whether you use the XVI reconstruction
or RTK. Since the Elekta system does not record your unattenuated signal
anywhere, it is not possible to do the proper I/I_0 normalization that you
need in order to get to the attenuation coefficients required for the HU
definition, and hence you cannot get to proper HU values from the projection
images alone. Due to detector drift and all the different sources of
artefacts in CBCT imaging, it is a non-trivial problem to get this
normalization right.

 

With the latest release of the Elekta XVI 5.0 software, there is some
calibration added on the software side to allow a pseudo-HU calibration of
the CBCT grey values. Since we do not have the software in our clinic yet, I
have not investigated how exactly this is incorporated. My guess is that it
is more of an empirical mapping which works well on objects of similar size,
shape and composition as the calibration phantom used, than it is a proper
calibration of all projection images to the open field images that would
give the correct normalization.

 

Hope this helps – otherwise feel free to ask again.

 

 

Best regards,

 

Rune Slot Thing

PhD Student

Institute of Clinical Research, University of Southern Denmark

Laboratory of Radiation Physics, Odense University Hospital

 <mailto:rune.slot.thing at rsyd.dk> rune.slot.thing at rsyd.dk

 

Fra: Rtk-users [mailto:rtk-users-bounces at public.kitware.com] På vegne af
Yang K Park 
Sendt: 3. marts 2015 02:05
Til: rtk-users at openrtk.org <mailto:rtk-users at openrtk.org> 
Emne: [Rtk-users] Obtaining HU number from RTK float data after CBCT
reconstruction

 

Hi RTK users,

 

This could be a class question but  I couldn’t have any chance to ask it so
far.

 

After the RTK reconstruction, I can get float values for each voxel which
might be linear attenuation coefficients (µ [mm-1]) coming from logarithm
calculation.

 

In my experience, this value is quite different from that of helical CT.

For example, µ for water ~= 0.015 [mm-1] in RTK (measured in regions without
scatter artifacts) vs ~0.027 [mm-1] in CT. And that µ value is also affected
by mAs value as well.

 

My goal is to convert that float value to HU number with a reasonable
explanation. 

 

In our Elekta system, they seem to convert those float values to their own
CBCT number ranging from “0-65535” by using a following formula:

 

Elekta CBCT number  = µ * 65536 – 1024  (µ seems to be the float value
identical to that comes from RTK reconstruction)

 

, which has no relationship to HU definition.

 

And I’m wondering why they are using the above formula instead of using
classic HU definition ( HU =  (µ - µ_w / µ_w)*1000). 

 

Of course I’m aware of that CBCT number should be quite different from CT
number due to many artifact sources.

I’m just trying to get some physically reasonable conversion method between
CBCT number to HU number.

 

Thank you guys for your help in advance!

 

Yang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20150303/49338eff/attachment-0009.html>