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: agravga...@protonmail.com Cell: +45 3165 8140 On Wed, 27 May 2020 at 06:00, Brani Rusanov <brani_rusa...@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 <andreasg...@gmail.com> > *Sent:* Tuesday, 26 May 2020 7:15 PM > *To:* Brani Rusanov <brani_rusa...@hotmail.com> > *Cc:* rtk-users@public.kitware.com <rtk-users@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: agravga...@protonmail.com > > Cell: +45 3165 8140 > > > On Tue, 26 May 2020 at 12:37, Brani Rusanov <brani_rusa...@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 <andreasg...@gmail.com> > *Sent:* Tuesday, 26 May 2020 4:51 PM > *To:* Brani Rusanov <brani_rusa...@hotmail.com> > *Cc:* rtk-users@public.kitware.com <rtk-users@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: agravga...@protonmail.com > > Cell: +45 3165 8140 > > > On Tue, 26 May 2020 at 05:08, Brani Rusanov <brani_rusa...@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@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> > >
_______________________________________________ Rtk-users mailing list Rtk-users@public.kitware.com https://public.kitware.com/mailman/listinfo/rtk-users
