Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orthovoltage treatment planning system #73

Open
cpinter opened this issue Sep 22, 2017 · 6 comments
Open

Orthovoltage treatment planning system #73

cpinter opened this issue Sep 22, 2017 · 6 comments
Assignees

Comments

@cpinter
Copy link
Member

cpinter commented Sep 22, 2017

Treatment planning system for orthovoltage RT, for treating skin lesions.

This will contain various file readers and converters, as well as a dose engine class that calls EGSnrc code after providing it the proper input.

Wiki page containing all project information:
https://github.com/SlicerRt/SlicerRT/wiki/Orthovoltage-RT

@cpinter cpinter added this to the Student projects milestone Sep 22, 2017
cpinter added a commit to SlicerRt/SlicerRtDoc that referenced this issue Sep 22, 2017
@cpinter
Copy link
Member Author

cpinter commented Sep 22, 2017

  • Duplicate VffFileReader module [2], call it DosxyzNrc3dDoseFileReader (Andras: please correct the name if you think it can be better)
    • Rename all files, all class names, etc to the new name. Read through the code carefully and change things as you go (name in license text, contributor, etc.)
    • The parameter defined in qSlicerVffFileReaderOptionsWidget won’t make sense in our case, but let’s leave it like that for now
  • Add the module to SlicerRT: edit the CMakeLists.txt file [3] (build SlicerRT and make sure it compiles, then commit to your branch – I’ll give you more info)
  • Edit the logic file [4] to read .3ddose files
    • Find a sample dose file here [5] (I just googled it and downloaded one I found in a ResearchGate discussion)
    • Check if the file complies with the specifications: Section 12 in [6]
    • Check out this Matlab reader script [7], see if it makes sense to port this to C++. Even if not, see what checks and verifications it makes, and build it into your code

[2] https://github.com/SlicerRt/SlicerRT/tree/master/VffFileReader
[3] https://github.com/SlicerRt/SlicerRT/blob/master/CMakeLists.txt
[4] https://github.com/SlicerRt/SlicerRT/blob/master/VffFileReader/Logic/vtkSlicerVffFileReaderLogic.cxx
[5] https://www.dropbox.com/s/fxrz88l3axdxjj4/Segment01.3ddose.zip?dl=0
[6] https://nrc-cnrc.github.io/EGSnrc/doc/pirs794-dosxyznrc.pdf
[7] https://www.mathworks.com/matlabcentral/fileexchange/55085-dosxyznrc-3ddose-file-reader

anna-ilina added a commit to anna-ilina/SlicerRT that referenced this issue Oct 23, 2017
anna-ilina added a commit to anna-ilina/SlicerRT that referenced this issue Oct 23, 2017
anna-ilina added a commit to anna-ilina/SlicerRT that referenced this issue Oct 23, 2017
anna-ilina added a commit to anna-ilina/SlicerRT that referenced this issue Oct 24, 2017
anna-ilina added a commit to anna-ilina/SlicerRT that referenced this issue Oct 26, 2017
anna-ilina added a commit to anna-ilina/SlicerRT that referenced this issue Oct 26, 2017
anna-ilina added a commit to anna-ilina/SlicerRT that referenced this issue Oct 26, 2017
cpinter pushed a commit that referenced this issue Oct 31, 2017
Includes option to set scaling factor for image intensity.

#73
@cpinter
Copy link
Member Author

cpinter commented Oct 31, 2017

Next task will be exporting plan and beam parameters that can be fed as input to the CCSEO EGSnrc engine.

Until we have access to an EGSnrc dose engine to test the development of this task, we will work on surface scanning:

  • Use Artec Eva on a phantom and a painted lesion to get a surface scan
  • Register surface scan to CT in Slicer (using ICP on subsampled surfaces)
  • Contour lesion using Segment Editor
  • Export to DICOM-RTSS

@cpinter
Copy link
Member Author

cpinter commented Feb 6, 2018

Surface scanning workflow has been developed by @anna-ilina, paper submitted to CARS 2018.

She is working on integrating ctcreate into the SlicerRT orthovoltage dose engine so that CTs can be automatically converted to the phantom format DOSXYZnrc requires.

@cpinter cpinter self-assigned this Feb 6, 2018
@cpinter
Copy link
Member Author

cpinter commented Feb 15, 2018

DOSXYZnrc inputs

cpinter pushed a commit that referenced this issue Feb 8, 2019
Re #73

--------------------------------------------

From https://github.com/anna-ilina/SlicerRT/commits/orthovoltage-rt-doseengine
Individual commits:
ENH: Make dosxyznrc callable from orthovoltage EBP module
ENH: Ctcreate using orthovoltage dose engine working
ENH: Add ctcreate parameters
ENH: Add orthovoltage dose engine to engines offered in external beam planning
@cpinter
Copy link
Member Author

cpinter commented Apr 5, 2019

After the latest meeting these are the remaining steps:

Needed for continuing Slicer development

  • Asymmetric virtual CT phantom (Chandra)
  • Phase space file, reasonably small for validation (Ingrid)
  • Config file for DOSXYZ run (Ingrid)
  • IEC -> DOSXYZ conversion equations (Ingrid)

Next steps in Slicer development (Csaba)

  • Meet with Ingrid, get data and config files, see one execution
  • IEC -> DOSXYZ angles conversion
  • Reproduction and validation of the test run of Ingrid
  • Save paths in Application Settings

cpinter added a commit that referenced this issue Jun 13, 2019
…g code

The beam parameters tab widget showed all tabs after loading the plan from scene. Now it is fixed.

Re #73
cpinter added a commit that referenced this issue Jun 17, 2019
Simple line edit type parameter was not set in the UI

Re #73
@cpinter
Copy link
Member Author

cpinter commented Jun 18, 2019

Further tasks:

  • Find reason for DICOM to DOSXYZ phicol beam angle difference (270 != 180)
  • Confirm with Ingrid that the DOSXYSnrc parameters are OK
  • Apply couch angle (*)
  • Automatically read back 3ddose file into output dose volume

* The reason the couch angle is not changed, is that it does not have an effect in SlicerRT since we implemented the Room’s Eye View module. The reason for that is that we have the linac in RAS=World=FixedReference(IEC) in Slicer, and the couch is just another coordinate system. The way to apply the couch angle would be to rotate the whole patient along the IS axis, however it is not currently implemented. This is the reason for the difference in theta. I will run the dose engine like this for testing, and then we can figure out how to take the couch angle into account.

cpinter added a commit that referenced this issue Jun 18, 2019
- ctcreate generation fixed and validated; Output handled and logged
- DICOM to DOSXYZnrc beam angle conversion function added; Added EGSnrcUtil.py containing common EGSnrc methods not specific to the orthovoltage use case
- DOSXYZnrc input parameters fixed
- DOSXZYnrc execution

Re #73
cpinter added a commit that referenced this issue Jun 18, 2019
The voxel values are so small that they cannot be managed in Slicer (W/L, threshold, Data probe etc.). A good default scaling seems to be 10^18

Re #73
cpinter added a commit that referenced this issue Jun 18, 2019
- When loading a scene a new markups POI node was created, because a temporary nullptr setting in the POI markups node combobox
- When plan node is selected that is not empty the instructions text is now cleared

Re #73
cpinter added a commit that referenced this issue Jul 3, 2019
Empty output total dose volume was created on setting the plan. This resulted in an invalid scene if was saved before dose calculation, which in turn resulted using a random volume node instead of the empty dose volume when calculating dose after loading that scene.
Now the output total dose can be set to None (the combobox will say 'Create new output dose volume') and the volume is only created when clicking the Calculate dose button.

Re #73
cpinter added a commit that referenced this issue Jul 4, 2019
The beam poly data in beam model node needs to be re-observed after import. Without this, the beam polydata display is not updated when the beam geometry changes. The reason for this is possibly that the pipeline is set up with the file reader and on any modified event that pipeline is used instead of simply using the changed contents of the beam polydata.

Re #73
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants