IndexError: index out of bounds during when obtaining the dose grid during DVH calculation

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load dicom-rt export from a plunc plan

What is the expected output? What do you see instead?

dicompyler.dvhcalc: DEBUG: Calculating DVH of 13 skin
dicompyler: ERROR: Unhandled exception: Traceback (most recent call last):
  File ""main.py"", line 691, in Run
  File ""threading.pyo"", line 484, in run
  File ""main.py"", line 438, in LoadPatientDataThread
  File ""dicompyler\dvhcalc.pyo"", line 21, in get_dvh
  File ""dicompyler\dvhcalc.pyo"", line 82, in calculate_dvh
  File ""dicompyler\dicomparser.pyo"", line 492, in GetDoseGrid
IndexError: index out of bounds"

Original issue reported on code.google.com by bastula on 2 Jan 2012 at 6:46

[GoogleCodeExporter]

Seems like the code that returns a slice of the dose grid is trying to access 
an index that does not exist.

Need to look at the code to make sure the indexing math is correct.

Original comment by bastula on 2 Jan 2012 at 6:48

• Added labels: Priority-High, Milestone-NextRelease
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I ran into something like this thinking it was caused by the reordering of FFS 
patients in r57d9155cc415.But it turned out that the rtplan image array was not 
the shape I expected. Is the doseGrid indexed assuming its the same number of 
CT slices or does the length of the GridFrameOffsetVector determine this?

Original comment by lstrd...@gmail.com on 4 Jan 2012 at 3:11

[GoogleCodeExporter]

The dose grid is indexed using (3004,000C) Grid Frame Offset Vector. The z 
position of the image is used to determine what relative slice to obtain from 
the dose grid. If the slice exists in the dose grid (using Grid Frame Offset 
Vector) it is returned, otherwise it is interpolated.

There is a possibility that the RT Dose file contains a (3004,000C) Grid Frame 
Offset Vector value of type B as seen in DICOM section C.8.8.3.2 (details can 
be found http://www.dabsoft.ch/dicom/3/C.8.8.3.2/ ).

dicompyler currently expects type A which states that the first element of Grid 
Frame Offset Vector is zero and uses relative Z coordinates. Type B uses 
absolute Z coordinates.

Is it possible for you to attach/send any data that has this bug? I am unable 
to reproduce the error because all the RT Dose data that I have is of type A.

Original comment by bastula on 8 Jan 2012 at 8:39

[GoogleCodeExporter]

Im afraid I am also limited to type A as well. So, I made a menu plugin which 
switches the current RTDose between a Type A/B Grid Frame Offset Vector.

You can use the plugin on a loaded patient w/ a rtplan. It requires 
re-selecting the rtdose file in the tree view, or changing the slice in 2dview 
to refresh the updated information. This is not causing any exceptions on the 
testdata or my usual thorax sample however.

Original comment by lstrd...@gmail.com on 9 Jan 2012 at 3:16

Attachments:

• GFOVswitch.py

[GoogleCodeExporter]

Sorry for the spam but I just noticed that I cannot force a recalculation of 
the DVH after switching the rtdose with my plugin. Would you happen to have any 
suggestions on how to trigger this from the plugin to allow us to test Type B 
properly?

Original comment by lstrd...@gmail.com on 9 Jan 2012 at 3:30

[GoogleCodeExporter]

If you delete the DVH sequence like in the plansum plugin, you can force a 
recalculation. See: 
http://code.google.com/p/dicompyler-plugins/source/browse/plugins/plansum/plansu
m.py for more information.

You must do this before republishing the data.

Don't forget to call: 
pub.sendMessage('patient.updated.raw_data', name_of_ptdata_variable)
when you want to republish the data.

Original comment by bastula on 18 Jan 2012 at 7:42

[GoogleCodeExporter]

This issue was closed by revision 21ffb60ee3b0.

Original comment by bastula on 9 May 2012 at 8:29

• Changed state: Fixed