Incorrect or Missing Rx Dose causes Errors

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open a set of dicom files including CT, Struct, Plan and Dose
2. Scroll through images works fine. When I select any of the available ROIs, I 
can see in the log that an exception has been raised [1].
3. When trying to scroll (mousewheel) through the images slices following this, 
nothing happens. I have to deselct the ROI in order to continue scrolling 
through the images.

What is the expected output? What do you see instead?
The expected output is to get structure information at the bottom left, and to 
be able to scroll through the images with the ROI delineated in the slices.

Instead I see no structure information and scrolling is halted.

What version of the product are you using? On what operating system?
dicompyler version 0.4a2
WinXp 32bit

Please provide any additional information below.
I dont know if this is related, but when I open the files, it complains that:
RX dose not found in RT Plan.

The DICOM files are exported from the Oncentra MasterPlan treatment planning 
system.

Regards,
Chris

Original issue reported on code.google.com by chris.le...@gmail.com on 28 Jul 2011 at 1:39

Attachments:

• dicompyler-open.png
• dicompyler-main.png

[GoogleCodeExporter]

I tried to attach the log, but it seems I lost it. Anyway, this is the log 
output:

Traceback (most recent call last):
  File "guiutil.pyo", line 228, in OnCheck
  File "wx\lib\pubsub.pyo", line 811, in sendMessage
  File "wx\lib\pubsub.pyo", line 498, in sendMessage
  File "wx\lib\pubsub.pyo", line 336, in sendMessage
  File "main.py", line 483, in OnStructureCheck
  File "main.py", line 530, in OnStructureSelect
  File "wx\lib\pubsub.pyo", line 811, in sendMessage
  File "wx\lib\pubsub.pyo", line 498, in sendMessage
  File "wx\lib\pubsub.pyo", line 336, in sendMessage
  File "H:\Projects\python\dicompyler\dist\baseplugins\dvh.py", line 179, in OnStructureSelect
  File "H:\Projects\python\dicompyler\dist\baseplugins\dvh.py", line 255, in OnToggleConstraints
  File "H:\Projects\python\dicompyler\dist\baseplugins\dvh.py", line 276, in OnChangeConstraint
  File "dvhdata.pyo", line 35, in GetVolumeConstraintCC
  File "dvhdata.pyo", line 29, in GetVolumeConstraint
IndexError: index out of bounds

Original comment by chris.le...@gmail.com on 28 Jul 2011 at 1:41

[GoogleCodeExporter]

I can also add that, when opening another set of DICOM files (exported by the 
same program), that does not include any RTDose or RTPlan files, I get no 
exception when selecting structures, and the scrolling works fine too following 
selection.

Original comment by chris.le...@gmail.com on 28 Jul 2011 at 1:44

[GoogleCodeExporter]

Hello Chris,

It seems that this is a problem with the DVH generation method. From your 
attached log and screenshots, it seems that your RT Dose file(s) do not contain 
DVH data so dicompyler will automatically calculate it.

Somehow, there is a bug in dvhdata which is used to access the generated DVH 
array in the DVH tab.

The effect of not being able to scroll through slices is a side effect of the 
fact that when you select and ROI, dicompyler simultaneously plots the 
structure on the 2D view and displays the DVH within the DVH tab.

I may have seen this error before so it will definitely be investigated.

Thanks for reporting this,

Adit

Original comment by bastula on 28 Jul 2011 at 1:56

• Changed state: Accepted
• Added labels: Usability

[GoogleCodeExporter]

I noticed I can reproduce this same error in the following scenarios:

1. Not entering any prescription dose in the "Open Patient" dialog.
2. Enter a grossly incorrect prescription dose (i.e. 1 cGy instead of 4500 cGy)

Note that these errors would only occur with RT Plan files that don't have 
prescription dose information.

If you try entering the correct prescription dose in the dialog, you should be 
able to get past this error.

The reason that the prescription dose is asked for at import time is because 
dicompyler relies on the it for the volume/dose constraint slider in the DVH 
view.

A potential workaround in the future is for dicompyler to guess the 
prescription dose based on the dose grid information.

Original comment by bastula on 1 Aug 2011 at 2:49

• Changed title: Incorrect or Missing Rx Dose causes Errors

[GoogleCodeExporter]

Thanks for your feedback on this issue.

I tried entering a sensible prescription dose and I didnt get the original 
error anymore. Im still not sure if the dose information that was listed by 
dicompyler was correct, it looked kind of strange at first sight, but I'll have 
to investigate a bit further before I can conclude on that.

I guess a nice addition to dicompyler would be for it to guess the prescription 
dose and offer that as the default value instead of the current default 1 cGy. 
One way of guessing this dose would be to look at the max dose in the pixel 
data, and take a percentage of that. I guess in most cases the prescription 
dose will be in the 90-95% range of the max dose in the dose distribution.

Regards,
Chris

Original comment by chris.le...@gmail.com on 2 Aug 2011 at 6:16

[GoogleCodeExporter]

The original premise of dicompyler was based on DVH constraints used the DVH 
plugin. Therefore, a lot of code has the prescription dose as a requirement. 
However, as more features are less reliant on prescription data, dicompyler 
will slowly be refactored to use absolute dose where relative dose is not 
required.

To that end, I think your suggestion of 90-95% of max dose is good. 
Unfortunately, in brachytherapy, the max dose far exceeds the prescription dose 
making the values look quite out of range (even more unfortunate is that 
BrachyVision does not export the Rx dose like Eclipse does).

Original comment by bastula on 16 Aug 2011 at 2:29

[GoogleCodeExporter]

The changeset r9e446b0dbe68 now allows the Rx Dose to be determined from the RT 
Plan Fractionation information if present. This should alleviate most users 
concerns except for brachytherapy plans.

Determining Rx Dose from a percent of the dose grid max should probably catch 
the rest of the edge cases.

Original comment by bastula on 11 May 2012 at 8:06

[GoogleCodeExporter]

Thanks for taking care of the issue!

Regards
Chris

Original comment by chris.le...@gmail.com on 13 May 2012 at 6:02