[Rtk-users] Unable to Forward Project CT Volume With Correct Orientation

Andreas Andersen andreasga22 at gmail.com
Wed May 27 03:10:34 EDT 2020 

Interesting, then maybe it is possible to standardise it.
I would prefer to have the normalisation in RTK if possible.
A value named KVNormChamber is read on this line:
https://github.com/SimonRit/RTK/blob/master/src/rtkXimImageIO.cxx#L73
But if I'm reading the section from the Thesis you linked right, I guess
we'd also need the I_0 value.
I think this must come from a file in the Calibrations folder, so it'll
have to be an optional feature and require a CLI flag pointing to the right
file (depending on the bow-tie type used if any).
I'm guessing the "KVNormChamber" value corresponds to NC_I, but is NC_I_0
then "KVNormChamber" in the calibration projection, or is it maybe the kV
value from the scan.xml file ?


P.S. Shameless promotion of my own project:
I wouldn't recommend getting CbctRecon just to normalise projections.
However, for the a priori scatter correction it will make your life easier:

   - Take a look at Testing/test_end_to_end.cpp for a somewhat short script
   doing the full correction (If you want to script it)
   https://gitlab.com/agravgaard/cbctrecon/-/blob/Develop/Testing/test_end_to_end.cpp#L176
   - Configure and build the whole thing if you want a user interface (UI
   works best on Windows) for the scatter correction:
   https://gitlab.com/agravgaard/cbctrecon/-/tree/Develop/#cbctrecon
   - It's optimised a lot and takes about 70 seconds for a full scatter
   correction (also including file-reading) on my Linux machine.
   - Although expanded from the original implementation by Yang et al., it
   avoids the "Correction Factor"
   - TBI: Two ongoing projects to automise the process, a minimal UI
   project and a clinical integration project (reconstructing as projections
   are captured with a frame-grabber).



P.P.S. There's quite a different between C and C++, in particular C++ 17
(or 20), below is a few of my favourite ressources for learning C++
(although I'm mostly self-taught by looking at other peoples code)

   - Jonathan Boccara's FluentC++ blog: https://www.fluentcpp.com/posts/
   For writing readable (expressive) C++ and understanding what's in the
   standard library
   - Jason Turner's Weekly C++ series on youtube:
   https://www.youtube.com/playlist?list=PLs3KjaCtOwSZ2tbuV1hx8Xz-rFZTan2J1
   - Bartek Filipek's blog: https://www.bfilipek.com/ For C++17, lambdas,
   and in general modern C++
   - Craig Scott's book: https://crascit.com/professional-cmake/ The single
   best ressource for all your CMake needs.
   - Rainer Grimm's blog: http://www.modernescpp.com/index.php For
   understanding threading, atomics, parallelism and functional programming in
   C++
   - Matt Godbolt's: https://godbolt.org/ Online compiler with all the
   compilers for quick and easy test of code snippets and compiler flags (you
   might also learn some assembly if you use it as often as I do)


/Andreas

__________________________________

Andreas Gravgaard Andersen

Danish Center for Particle Therapy,

Aarhus University Hospital

Palle Juul-Jensens Blvd. 99,

8200, Aarhus

Mail:     agravgaard at protonmail.com

Cell:      +45 3165 8140


On Wed, 27 May 2020 at 06:00, Brani Rusanov <brani_rusanov at hotmail.com>
wrote:

>
> Hi Andreas,
>
> Your input is invaluable, thanks for your suggestions! You are correct, I
> am attempting to apply the a priori scatter correction. Is the
> normalisation procedure you mentioned regarding the calibration-chamber
> similar to what has been mentioned on page 63-64 of this thesis (
> https://pdfs.semanticscholar.org/d90c/d77b61d10d2c24df0686bc0be1f38424d67d.pdf),
> specifically Norm Chamber (NC) values located in raw projection header?
>
> I will admit, I am a complete novice when it comes to C coding and using
> RTK. For correctly normalising the Varian projections do you recommend
> installing your "cbctrecon" package? If so, which function performs the
> Varian normalisation? Or can the normalisation be done by scaling the
> projection pixel values manually? My plan is to manually scale the CB
> projections and perform a reconstruction until the HU looks right. A more
> robust method is preferable, however.
>
> Your advice is greatly appreciated,
> Brani
> ------------------------------
> *From:* Andreas Andersen <andreasga22 at gmail.com>
> *Sent:* Tuesday, 26 May 2020 7:15 PM
> *To:* Brani Rusanov <brani_rusanov at hotmail.com>
> *Cc:* rtk-users at public.kitware.com <rtk-users at public.kitware.com>
> *Subject:* Re: [Rtk-users] Unable to Forward Project CT Volume With
> Correct Orientation
>
> I'm happy to hear it worked!
>
> I don't know the complete Varian pipeline for correction, there should in
> addition to subtracting the bow-tie be something like a
> calibration-chamber-based correction, but I have not figured out how to do
> this (let me know if you do)
> RTK does not have filters to take care of this (yet). It would be possible
> to do, but you'd have to know which image in the calibration folder is the
> correct one. (There may be several and I think they are named by the local
> Varian engineers - not standardised)
> I do a simple subtraction in my own OpenCL implementation, but looping
> through projections, extracting 2D from 3D, and using the ITK subtraction
> image filter would probably be simpler.
> (*If I should find documentation from Varian describing this process with
> some standard, I'll write it into the reader for Xim images. However, I'm
> afraid their own solution might specific to each gantry or engineering team*
> )
>
> It could sound like you want to do the "a priori scatter correction", I've
> implemented this for Varian based projections (hnd and xim), see:
> gitlab.com/agravgaard/cbctrecon
> <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgitlab.com%2Fagravgaard%2Fcbctrecon&data=02%7C01%7C%7C63220d57e95844eb634508d8016629c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260885580829813&sdata=Hiyv%2BwFoqjeHcqAH3jIG%2B5aiyqKnurLJ0qQ6ax4N3ug%3D&reserved=0>
> (The Develop branch should be preferred at the moment)
> The correction factor from the original Elekta implementation doesn't work
> without a normalisation as mentioned above, so I'm doing some tricks to
> ensure correctness of projection intensity for the subtraction, but I hope
> to implement a solution/normalisation based on numbers from the machine
> instead.
>
> /Andreas
>
> __________________________________
>
> Andreas Gravgaard Andersen
>
> Danish Center for Particle Therapy,
>
> Aarhus University Hospital
>
> Palle Juul-Jensens Blvd. 99,
>
> 8200, Aarhus
>
> Mail:     agravgaard at protonmail.com
>
> Cell:      +45 3165 8140
>
>
> On Tue, 26 May 2020 at 12:37, Brani Rusanov <brani_rusanov at hotmail.com>
> wrote:
>
> Hi Andreas,
>
> You are correct, I had failed to flip the y and z coordinates of the
> offset parameter in the header. I had thought that the transformmatrix
> would take care of this. Now the simulated projection looks as desired.
> Thank you!
>
> You mentioned the possibility of applying pre-processing on the CB
> projections for a bow-tie filter. Do you know what kind of pre-processing
> is available within RTK for bow-tie filters? I ask because I plan on
> subtracting the measured CBCT projections from the simulated CT-registered
> projections. However, the measured CBCT projections have the characteristic
> attenuation pattern on the left and right side of the image corresponding
> to a bow-tie filter. Can RTK remove these two regions of greater
> attenuation?
>
> Also, would you happen to know if rtkprojections, when converting the raw
> projection float values to attenuation, is compatible with Varian raw
> projection data? I ask this because the studies I have read that perform
> this procedure use Elekta projection data. The output attenuation values
> for my measured projection data in air region is about ~2 mm-1 after
> conversion with rtkprojections. Whereas, I previously converted the HU of
> the registered CT volume to attenuation using the formula: mu = (HU +
> 1024)/2^16 which shows air to be ~0.019mm-1 once forward projected.
>
> Thank you kindly for your advice,
> Brani
> ------------------------------
> *From:* Andreas Andersen <andreasga22 at gmail.com>
> *Sent:* Tuesday, 26 May 2020 4:51 PM
> *To:* Brani Rusanov <Brani_Rusanov at hotmail.com>
> *Cc:* rtk-users at public.kitware.com <rtk-users at public.kitware.com>
> *Subject:* Re: [Rtk-users] Unable to Forward Project CT Volume With
> Correct Orientation
>
> What do you more precisely mean by "The output projections do not look
> like the raw projections I have from the CBCT"
> Are they flipped, are they all black, are they much brighter or darker, or
> do they not align?
>
> If alignment: Consider if you need to sort the projections by gantry angle
> before visual comparison, the Xim reader just reads sequentially by the
> given regex, so a ProBeam CB (with two imagers) may interleave projections
> from different angles. This is unlikely to be a problem for a gantry with
> only one imager.
>
> If flipped or all black: Your transformation matrix looks correct to me,
> so I think the problem may be elsewhere.
> It's always a mess to figure out. Be careful, that when you flip axes
> manually like that that you also remember to flip offsets (origin),
> spacing, etc. accordingly.
> In particular orientation (directions), I can see it says RAI for
> "AnatomicalOrientation", but I think you'll need the "Orientation" tag with
> direction cosines if you want to specify the directions manually.
> https://itk.org/Wiki/ITK/MetaIO/Documentation#MetaObject_Tags
> <https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fitk.org%2FWiki%2FITK%2FMetaIO%2FDocumentation%23MetaObject_Tags&data=02%7C01%7C%7C63220d57e95844eb634508d8016629c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260885580839808&sdata=v2SPprbq57AoHf3VyamdMKStgCNsVK0HozMmmJbI3dM%3D&reserved=0>
>
> All this being said, I would suggest to instead use ITK's readers and the
> built-in filters for image transformation if that's even necessary, to
> avoid the hell of trying to keep track of all these values manually.
>
> If intensity is darker or brighter: Check if you have preprocessed the CB
> projections correctly for bow-tie filter and the like.
>
> I hope this gives a hint to where the problem might be.
>
> /Andreas
>
> __________________________________
>
> Andreas Gravgaard Andersen
>
> Danish Center for Particle Therapy,
>
> Aarhus University Hospital
>
> Palle Juul-Jensens Blvd. 99,
>
> 8200, Aarhus
>
> Mail:     agravgaard at protonmail.com
>
> Cell:      +45 3165 8140
>
>
> On Tue, 26 May 2020 at 05:08, Brani Rusanov <Brani_Rusanov at hotmail.com>
> wrote:
>
> Hi all,
>
> I am attempting to forward project a CT volume (previously registered to a
> CBCT volume) using the geometry of a CBCT volume to generate raw
> projections. I also have access to the raw CBCT projections. I have used
> rktprojections to stack the raw CBCT projections and generate .mhd/raw
> files.
>
> Next, I used rtkvariabprobeamgeometry on the scan.xml file that came with
> the raw CBCT projections to generate a RTK compatible geometry.xml file.
>
> Next, I have stacked the registered CT dicoms into a .mhd/raw format. The
> trouble I'm having is creating the projections using rtkforwardprojections.
> Specifically, I cannot find the correct transformmatrix in the CT header to
> tell rtkforwardprojetions the conversion from DICOM to IEC geometry. The
> output projections do not look like the raw projections I have from the
> CBCT. This may be a stupid question, but I cannot figure it out. From my
> own estimation, the transformation should be 1 0 0 0 0 -1 0 1 0 based on
> this diagram (
> https://www.semanticscholar.org/paper/nuclear-science-and-technology-Radiation-Quantities-Brink-McNitt-Gray/1ec27be3617dfc4e03bba86dcd92db8f3323de21/figure/3
> <https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.semanticscholar.org%2Fpaper%2Fnuclear-science-and-technology-Radiation-Quantities-Brink-McNitt-Gray%2F1ec27be3617dfc4e03bba86dcd92db8f3323de21%2Ffigure%2F3&data=02%7C01%7C%7C63220d57e95844eb634508d8016629c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260885580849808&sdata=%2BcHqKs1UZFalgC6Aug0OUp8qmGor5gm2ubuS5FmwoJg%3D&reserved=0>
>
> <https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.semanticscholar.org%2Fpaper%2Fnuclear-science-and-technology-Radiation-Quantities-Brink-McNitt-Gray%2F1ec27be3617dfc4e03bba86dcd92db8f3323de21%2Ffigure%2F3&data=02%7C01%7C%7C63220d57e95844eb634508d8016629c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260885580859815&sdata=E3D3%2FE%2FFGybdE%2FFPZGFIuN8nGTwrd8NNiLP%2BhtXthdE%3D&reserved=0>
> Figure 1.4 from nuclear science and technology Radiation Quantities and
> Units , Dose to the Patients , and Image Quality in Computed Tomography (
> CT ) ( RAD UNITS ) Author : | Semantic Scholar
> <https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.semanticscholar.org%2Fpaper%2Fnuclear-science-and-technology-Radiation-Quantities-Brink-McNitt-Gray%2F1ec27be3617dfc4e03bba86dcd92db8f3323de21%2Ffigure%2F3&data=02%7C01%7C%7C63220d57e95844eb634508d8016629c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260885580869808&sdata=jvzkLIg7%2FGfktUYgbxwd7Um%2BIAG3jnivsoo0sitiFEw%3D&reserved=0>
> Figure 1.4 (left) The IEC patient coordinate system (the patient is lying
> in supine position); (right) transformation of coordinates between the IEC
> and DICOM coordinate systems [IEC, 2000] (cited in ICRU Report 71, 2004,
> page 35) - "nuclear science and technology Radiation Quantities and Units ,
> Dose to the Patients , and Image Quality in Computed Tomography ( CT ) (
> RAD UNITS ) Author :"
> www.semanticscholar.org
> <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.semanticscholar.org%2F&data=02%7C01%7C%7C63220d57e95844eb634508d8016629c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260885580879808&sdata=rVbKGVfyqhrgyhcDV%2BON%2F%2FavYdAuXYUzWsKQgLpps%2FA%3D&reserved=0>
> )
>
> My questions are: Is this the correct transformmatrix to apply?
> Do I need to also change the offset values in order to get the correct
> projections?
> Could this have something to do with the fact that I am using variant data?
>
> The .mhd for the registered CT is:
> ObjectType = Image
> NDims = 3
> BinaryData = True
> BinaryDataByteOrderMSB = False
> CompressedData = False
> TransformMatrix = 1 0 0 0 0 -1 0 1 0
> Offset = -131.03451538085938 -131.03451538085938 -91.809638977050781
> CenterOfRotation = 0 0 0
> AnatomicalOrientation = RAI
> ElementSpacing = 0.51285523409720002 0.51285523409720002 1.9958648681640625
> DimSize = 512 512 93
> ElementType = MET_DOUBLE
> ElementDataFile = CIRS_6A.raw
>
> Similarly, the .mhd for the raw CBCT projections is:
> ObjectType = Image
> NDims = 3
> BinaryData = True
> BinaryDataByteOrderMSB = False
> CompressedData = False
> TransformMatrix = 1 0 0 0 1 0 0 0 1
> Offset = -198.46200000000002 -148.798 0
> CenterOfRotation = 0 0 0
> AnatomicalOrientation = RAI
> ElementSpacing = 0.38800000000000001 0.38800000000000001 1
> DimSize = 1024 768 501
> ElementType = MET_FLOAT
> ElementDataFile = CIRS_6A_SCGH_P.raw
>
> Thank you kindly for your response,
> Brani
>
> _______________________________________________
> Rtk-users mailing list
> Rtk-users at public.kitware.com
> https://public.kitware.com/mailman/listinfo/rtk-users
> <https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Frtk-users&data=02%7C01%7C%7C63220d57e95844eb634508d8016629c0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260885580889790&sdata=P7oUcTzE8acsSOlau9pS9WtPtRqDU1MyE9vQ%2BxPxRnk%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/rtk-users/attachments/20200527/3b369619/attachment-0001.htm>

More information about the Rtk-users mailing list