search

pombreda / dicompyler

Automatically exported from code.google.com/p/dicompyler
0 stars 0 forks source link

Cannot view Pinnacle3 files properly #22

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. installed dicompyler using the windows installer on a Windows 7 64 bit system
2. Open Patient ...., find the required patient, select, and enter the 
prescription dose (7000cGy)
3. load is successful

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

expect to see Structures, Isodoses and a CT with overlays
I see Structures list, Isodoses list and a three tab view called '2D view' (but 
.... NO CT IMAGE); 'DVH' (has the axes but no lines for selected structures) 
and 'DICOM Tree' (lists the file headers).

What version of the product are you using? On what operating system?

dicompyler version 0.3, on Windows 7 64-bit

Please provide any additional information below.

patient planned on Pinnacle V9.0

Original issue reported on code.google.com by alexisan...@gmail.com on 10 Nov 2010 at 4:29

GoogleCodeExporter commented 9 years ago 
some screenshots

Original comment by alexisan...@gmail.com on 10 Nov 2010 at 4:35

Attachments:

GoogleCodeExporter commented 9 years ago 
I have tried to load the same file on a Ubuntu 10.10 install of dicompyler, 
WITH THE SAME RESULT.

PS: I can view the CT files in Aeskulap. CTs were taken from a SIEMENS 
SENSATION OPEN CT

Original comment by alexisan...@gmail.com on 10 Nov 2010 at 5:41

GoogleCodeExporter commented 9 years ago 
in the linux install, I have copied the CLI messages:

Reading: rtplan.dcm
Reading: rtss.dcm
Found ROI #1: iso
Found ROI #2: laser
Found ROI #3: calc pt
Found ROI #4: GTVr
Found ROI #5: CTVr
Found ROI #6: CTV0
Found ROI #7: PAROTID_R
Found ROI #8: SUBMAN_R
Found ROI #9: SPINAL_CORD
Found ROI #10: AIR_TISSUE
Found ROI #11: CTVn0
Found ROI #12: MANDIBLE
Found ROI #13: PTV60
Found ROI #14: PTV70
Found ROI #15: PTV_PRV
Found ROI #16: PAROTID_R_PRV
Found ROI #17: SUBMAN_R_PRV
Found ROI #18: SPINAL_CORD_PRV3
Found ROI #19: MUCOSA
Found ROI #20: MUCOSA_PRV
Found ROI #21: MANDIBLE_PRV
Found ROI #22: External ROI_1
Found ROI #23: skin-0.5
Found ROI #24: planning PTV70
Found ROI #25: Planning PTV60
Found ROI #26: Ring70
Found ROI #27: Ring60
Found ROI #28: Post Avoid
Found ROI #29: hot avoid2
Found ROI #30: ant avoid
Traceback (most recent call last):
  File "/home/andrew/dicompyler/baseplugins/2dview.py", line 341, in OnPaint
    self.images[self.imagenum-1].GetImage(self.window, self.level))
  File "/home/andrew/dicompyler/dicomparser.py", line 161, in GetImage
    image = self.GetLUTValue(self.ds.pixel_array, window, level)
  File "/home/andrew/dicompyler/dicomparser.py", line 169, in GetLUTValue
    [data <= (level - 0.5 - (window-1)/2),
TypeError: unsupported operand type(s) for -: 'list' and 'float'
Traceback (most recent call last):
  File "/home/andrew/dicompyler/baseplugins/2dview.py", line 341, in OnPaint
    self.images[self.imagenum-1].GetImage(self.window, self.level))
  File "/home/andrew/dicompyler/dicomparser.py", line 161, in GetImage
    image = self.GetLUTValue(self.ds.pixel_array, window, level)
  File "/home/andrew/dicompyler/dicomparser.py", line 169, in GetLUTValue
    [data <= (level - 0.5 - (window-1)/2),
TypeError: unsupported operand type(s) for -: 'list' and 'float'

Original comment by alexisan...@gmail.com on 10 Nov 2010 at 2:11

GoogleCodeExporter commented 9 years ago 
Hi Andrew,

Thank you for going to great lengths to find out what is the cause of the 
problem. It seems that the window and level values might be stored as different 
data types. Normally they are stored as decimal strings - which are equivalent 
to floating point values. But this is not the case in the file above.

That would explain why the CT images are not showing up, as the drawing 
pipeline gets interrupted. So nothing whatsoever gets displayed in the 2D View 
tab.

Regarding the DVH tab, you probably won't see anything unless the RT Dose file 
contains DVH arrays. The pinnacle data that I have does not have this, and I am 
not sure if you can choose in Pinnacle to export this. The ability to calculate 
DVH directly from the RT Dose grid will be coming soon and should resolve this.

Would it be possible for you to anonymize the data using dicompyler (or other 
means) and send it to me somehow (Dropbox or other means)?

Thanks,

Adit

Original comment by bastula on 10 Nov 2010 at 2:31

GoogleCodeExporter commented 9 years ago 
You could also just zip the CTs and attach them here if you feel comfortable 
with that (and they are under the 10 MB limit).

Original comment by bastula on 10 Nov 2010 at 2:32

GoogleCodeExporter commented 9 years ago 
Maybe we should just force the type on level and window.

if ((window == None) and (level == None)):
            window = self.ds.WindowWidth
            level = self.ds.WindowCenter
else:
            window =  float(window)
            level = float(level)

alexisandrew, do you remember any specific options you chose when exporting the 
plan to dicom-RT on Pinnacle?

Original comment by roy.coding@gmail.com on 10 Nov 2010 at 5:17

GoogleCodeExporter commented 9 years ago 
We don't know yet if it is a float or a list of floats yet. I would like to 
know what is being sent over. Also we don't know yet if this is an issue with 
Pinnacle itself or the CT scanner as Pinnacle may not mangle the tags like some 
other TPSs do i.e. CMS XiO.

But yes, ideally we should convert it to a float. The DICOM standard states it 
should be a decimal string.

Adit

Original comment by bastula on 10 Nov 2010 at 5:39

GoogleCodeExporter commented 9 years ago 
I did that last night to my dropbox account, ill send link soon

AAM (from android phone)

Updates:
       Owner: bastula
       Labels: -Priority-Medium Priority-High Usability

Original comment by alexisan...@gmail.com on 10 Nov 2010 at 9:12

GoogleCodeExporter commented 9 years ago 
thank you for questions roy.coding.

I pointed the "open Patient" browser to the directory and entered it and then 
selected 'Open". I then set the prescription dose at 7000cGy and loaded the 
file.

Does it make a difference which layer is selected to load? I used the lowest.

Bastula can send you the link for the DICOM-RT directory if you wish.

Original comment by alexisan...@gmail.com on 11 Nov 2010 at 1:46

GoogleCodeExporter commented 9 years ago 
The more "layers" you load on the tree, the more data that will be
loaded and displayed. Each deeper layer will open that file and the
corresponding dependencies above as well.

For example, if you only want to open the CT data, you can just
highlight the series. If you want to open CT data and the RT
Structures, highlight the RT Structures.

I have now fixed the issue, so that the CT data loads. However, the RT
Structures do not show up properly. It will take some more time to
investigate into this, as I can see the external contour on the first
few slices, but then it disappears.

Original comment by bastula on 11 Nov 2010 at 2:36

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision 6d29e2da29.

Original comment by bastula on 11 Nov 2010 at 2:43

GoogleCodeExporter commented 9 years ago 
Changing the title to more correctly reflect the current issue, as there is 
another issue (Issue 20) regarding complete inability to import Pinnacle files.

Original comment by bastula on 11 Nov 2010 at 2:55

GoogleCodeExporter commented 9 years ago 
OK.

Question - how do I incorporate the altered files in the Windows environment?

Original comment by alexisan...@gmail.com on 11 Nov 2010 at 3:11

GoogleCodeExporter commented 9 years ago 
If you are using the executable version on Windows, you should be able
to just replace 2dview.py (which is a plugin) in the baseplugins
folder in the dicompyler installation folder. I think the error gets
caught early enough in 2dview.py that not replacing dicomparser.py
should be ok.

Unfortunately, you cannot modify the executable itself, so
dicomparser.py cannot be replaced, as the core files are bundled into
the exe. However, you can run from source as you have done with the
linux version, if you wish.

Original comment by bastula on 11 Nov 2010 at 3:21

GoogleCodeExporter commented 9 years ago 
no, the file is 2dview.py*o*, not 2dview.py.

PY is in text and 152KB in size, PYO is in Windows gobble-de-gook and 15KB
in size!

A

Original comment by alexisan...@gmail.com on 11 Nov 2010 at 3:27

GoogleCodeExporter commented 9 years ago 
You should be able to safely delete (or put aside) 2dview.pyo - as
that is optimized bytecode. Once you put 2dview.py in that folder and
re-run dicompyler, it will regenerate a .pyo or .pyc file as there is
an embedded python interpreter inside of the executable.

Original comment by bastula on 11 Nov 2010 at 3:44

GoogleCodeExporter commented 9 years ago 
Sorry, not working now!

I deleted the PYO file and added in the new PY file and got the associated
error message. Interesting that I can't actually see the log file.

A

Original comment by alexisan...@gmail.com on 11 Nov 2010 at 7:58

GoogleCodeExporter commented 9 years ago 
Additional to comment 17 - sorry, image file not attached when sending reply 
from Gmail.

Original comment by alexisan...@gmail.com on 11 Nov 2010 at 7:59

Attachments:

GoogleCodeExporter commented 9 years ago 
on UBUNTU install:

I copied 2dview.py and dicomparser.py and replaced the new version in the 
directory tree structure. On restart and load the DICOM-RT dataset I have 
uploaded for you, two things happen:

1. there are TWO 2D View tabs on the GUI. I problem solved that one! I had 
renamed 2dview.py to OLD_2dview.py. When I renamed it to OLD_2dview.txt that 
problem was solved.
2. there is a great deal of error messages in the CLI. I suspect that I do not 
have all of them, BUT they are the same recurring error (with each with each 
DCM file load attempt perhaps?). The error message is listed below.
------------------------------------------

Traceback (most recent call last):
  File "/home/andrew/dicompyler/baseplugins/2dview.py", line 349, in OnPaint
    self.images[self.imagenum-1].GetImage(self.window, self.level))
  File "/home/andrew/dicompyler/dicomparser.py", line 171, in GetImage
    return Image.fromarray(image).convert('L')
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1886, in fromarray
    raise TypeError("Cannot handle this data type")
TypeError: Cannot handle this data type

Original comment by alexisan...@gmail.com on 11 Nov 2010 at 9:44

GoogleCodeExporter commented 9 years ago 
File "/home/andrew/dicompyler/baseplugins/2dview.py", line 349, in OnPaint
    self.images[self.imagenum-1].GetImage(self.window, self.level))

I had a look at the code and the only thing that I wondered about was why the 
line was separated. I know some languages ignore white space but might this be 
the problem here?

File "/home/andrew/dicompyler/dicomparser.py", line 171, in GetImage
    return Image.fromarray(image).convert('L')

I had a look at this code and the only thing I could find was the fact that 'L' 
does not appear anywhere else in the file, so I was wondering what it means?

Original comment by alexisan...@gmail.com on 11 Nov 2010 at 9:53

GoogleCodeExporter commented 9 years ago 
I have noticed that on Windows 7 (possibly Vista) you cannot write files to the 
Program Files directory anymore due to user permissions. I have already set the 
database to write to a folder in the user's account instead. I will make a new 
issue regarding this for the log file.

I am assuming you are running from source (probably from mercurial) so the best 
way to update the code is to follow the mercurial "hg pull" and "hg update" 
commands. Please follow the  directions on 
http://code.google.com/p/dicompyler/wiki/BuildRequirements for more 
information. With source control, it doesn't make much sense to just copy 
files, when the mercurial commands can take care of this for you with much less 
headache.

I ran the latest source on Ubuntu 10.10 with your DICOM-RT data and I cannot 
reproduce what you are seeing. I get the expected result in the attached 
screenshot. It seems like you may have a different version of PIL (Python Image 
Library). The latest version is 1.1.7 and I think is by default included with 
Ubuntu 10.10.

I will send a copy of the data to Roy to see if he can reproduce, since he is 
more familiar with Linux.

Original comment by bastula on 11 Nov 2010 at 3:34

Attachments:

GoogleCodeExporter commented 9 years ago 
I did the 'hg' thing (pull and updated). Silly me, you are right of course.

My PIL comes from the Ubuntu repositories. I have an installed file called 
"python-imaging" and it is at version 1.1.7-2.

After the hg update, same thing. Error message remains.

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

Traceback (most recent call last):
  File "/home/andrew/dicompyler/baseplugins/2dview.py", line 348, in OnPaint
    image = guiutil.convert_pil_to_wx(self.images[self.imagenum-1].GetImage(self.window, self.level))
  File "/home/andrew/dicompyler/dicomparser.py", line 171, in GetImage
    return Image.fromarray(image).convert('L')
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1886, in fromarray
    raise TypeError("Cannot handle this data type")
-------------------------------------------------------
My Ubuntu 10.10 is only 5 days old.

Original comment by alexisan...@gmail.com on 11 Nov 2010 at 4:41

GoogleCodeExporter commented 9 years ago 
Windows 7: I downloaded your testdata file and that works.

I will try the same on Ubuntu tonight.

A

Original comment by alexisan...@gmail.com on 11 Nov 2010 at 11:24

GoogleCodeExporter commented 9 years ago

Original comment by bastula on 12 Nov 2010 at 4:23

GoogleCodeExporter commented 9 years ago 
I rolled pydicom back to version 0.9.4, and now I can see the CT images from my 
own files. 

But I can't see ROI structures, or dose.

I downloaded the TESTDATA file, and that displays correctly, so my Ubuntu 
install now looks good.

I didn't get the pydicom comments though. The first comment says "pydicom 0.9.5 
NOT supported", but the last sentence seems to say "pydicom 0.9.5 supported". 
Maybe its just my age??

Thanks for doing all this fixing. My physics guys have been very impressed. 
When I run my first Oncology Informatics Conference, you're on the invite list!

Original comment by alexisan...@gmail.com on 13 Nov 2010 at 7:13

GoogleCodeExporter commented 9 years ago 
I think what Adit's comments about pydicom 0.9.5 in issue 24 mean are that 
dicompyler does not yet work with pydicom 0.9.5. The second part is that 
pydicom 0.9.5 fixes a pydicom 0.9.4 bug that currently affects dicompyler.

I opened your pinnacle data with dicompyler on Ubuntu 10.04 and had the same 
outcome you last reported (i.e. images, but no contour or isodose data). Not 
sure what's going on. No error messages that I saw, so we'll have to dig deeper.

Original comment by roy.coding@gmail.com on 13 Nov 2010 at 9:48

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision 8ef90aca02.
Structures from Pinnacle should now display properly due to a discrepancy 
between the z coordinate in the structure data vs. the image data.
This occurs when the z coordinates are close but not exactly the same value.

Original comment by bastula on 23 Nov 2010 at 4:22

GoogleCodeExporter commented 9 years ago 
I copied the new source into PY files and substituted them in the dicompyler 
directory at the right places. I started dicomyler and all was well. I then 
tried to open one of the Pinnacle datasets that I have used before and this 
message appears in the terminal:

andrew@andrew-desktop:~/dicompyler$ ./main.py
Plugin: 2dview loaded
Plugin: anonymize loaded
Plugin: dvh loaded
Plugin: treeview loaded
Reading: breast.zip
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/andrew/dicompyler/dicomgui.py", line 199, in DirectorySearchThread
    dp = dicomparser.DicomParser(filename=dcmfile)
  File "/home/andrew/dicompyler/dicomparser.py", line 24, in __init__
    self.ds = dicom.read_file(filename, defer_size=100, force=True)
TypeError: read_file() got an unexpected keyword argument 'force'

** (python:10218): CRITICAL **: clearlooks_style_draw_flat_box: assertion 
`width >= -1' failed

** (python:10218): CRITICAL **: clearlooks_style_draw_flat_box: assertion 
`width >= -1' failed

The 'Open Patient' window opens and continues searching.

Sorry for being a nag!

Original comment by alexisan...@gmail.com on 23 Nov 2010 at 8:04

Attachments:

GoogleCodeExporter commented 9 years ago 
Additional: I also tried to open a DICOM diagnostic set that worked earlier in 
the week and there is the same outcome.

Original comment by alexisan...@gmail.com on 23 Nov 2010 at 8:07

GoogleCodeExporter commented 9 years ago 
You need to upgrade to pydicom 0.9.5 as that has become mandatory as of 
revision ab434c5ad5.

Original comment by bastula on 23 Nov 2010 at 8:39

GoogleCodeExporter commented 9 years ago 
any chance of a recompile of the latest changes to produce a new Windows
installer? A

Original comment by alexisan...@gmail.com on 24 Nov 2010 at 3:09

GoogleCodeExporter commented 9 years ago 
Another step forward!

I have replace pydicom-0.9.5 in my Ubuntu install, and here is the new screen 
dump.
1. successful display of DICOM file
2. successful display of ROIs
BUT .....
3. there is no dose overlay. 
[With respect to dose overlay, I am a very ICRU-type of guy, so 95% and 107% 
are crucial. Rather than add in 107%, is it possible to have a mechanism for 
adding other %s or cGys (my IMRT plans can have odd numbers as I dose paint).]

Can I say that you guy/s are just marvellous with this project. Once the 
DICOM-RT review works, I'll look at integration into a PACS.

A

Original comment by alexisan...@gmail.com on 24 Nov 2010 at 7:45

Attachments:

GoogleCodeExporter commented 9 years ago 
Apologies, I AM WRONG! well, sort of!

I was looking around the image some more, and THE ISODOsES ARE THERE!!! ...
BUT ....
they are not overlapping the right places on the scan. The previous picture has 
the isodoses turned on, but none to see. The next picture shows where they are 
- a long way superior and not looking like the isodose distribution that I 
accepted (which was very, very conformal to PTV60 and PTV60)

Original comment by alexisan...@gmail.com on 24 Nov 2010 at 7:55

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Surprise! Surprise! Surprise!!

I was scrolling down to the bottom of the image set and there in the lower 
reaches are more isodoses! These also don't match the actual pattern.

Sorry for finding so many problems and not being able to fix them or even 
attempt.

Original comment by alexisan...@gmail.com on 24 Nov 2010 at 8:06

Attachments:

GoogleCodeExporter commented 9 years ago 
It's all coming soon :) It takes time - along with school and other priorities.

The dose display doesn't work because of Issue 19. That's the next priority.
Support for adding/removing/modifying the isodose lines is planned - I will 
make a new issue for it.

Please also consider joining our Google Group: 
http://groups.google.com/group/dicompyler as other people might have issues 
like yours.

Additionally, if you want to see the latest compatibility info, please check 
the wiki page: http://code.google.com/p/dicompyler/wiki/DICOMCompatibilityGuide
It is updated whenever features are added and are verified to work with 
specific vendor data.

Furthermore, if you want to know when the source code (or project in general) 
has been updated, you can view the latest updates here: 
http://code.google.com/p/dicompyler/updates/list or subscribe to an RSS feed 
there as well. The same information is also duplicated on twitter at: 
http://twitter.com/dicompyler_dev

Windows build will come with 0.4, but I will see if I have time to make one 
once the dose is straightened out.

Original comment by bastula on 24 Nov 2010 at 8:09

GoogleCodeExporter commented 9 years ago 
thanks, I'll have a look at that stuff. But you have seen most of my
usefulness to you - play and break, and ask for new things!

A

-- 
-----------------
Prof. Andrew Miller, B.Med, B.Sc, Grad.Dip.Ed, FRANZCR

Radiation Oncologist, Illawarra Cancer Care Centre, Wollongong, NSW 2500
Australia
http://radonc.wikidot.com/

Clinical Professor, Graduate School of Medicine, University of Wollongong
http://www.uow.edu.au/~amiller

Director, Centre for Oncology Informatics, University of Wollongong
http://dlab.uow.edu.au/coi

Journal Manager, Journal for Radiation Oncology Informatics
http://www.jroi.org/index.php/jroi

Original comment by alexisan...@gmail.com on 24 Nov 2010 at 9:08

GoogleCodeExporter commented 9 years ago 
Yes. We really appreciate all of your hard work! Your enthusiasm and desire to 
make dicompyler work flawlessly is a testament to how useful open source can be 
for our field.

Original comment by bastula on 24 Nov 2010 at 9:16

GoogleCodeExporter commented 9 years ago 
Issue 19 has been fixed, so isodoses should be displayed properly. There are 
some artifacts with the actual drawing of the curves, but that is a different 
issue altogether.

Please see the issue for more information.

Original comment by bastula on 26 Nov 2010 at 10:12

Attachments:

GoogleCodeExporter commented 9 years ago 
The dose display now seems to be situated in the right part of the patient, 
however the  isodose display is not right. The last screen shot above shows the 
80% isodose running through the cord (i.e., cord dose ~56Gy), and I can assure 
you that this is not the case (cord max ~45Gy)!

I have a pixellated dose dump from Pinnacle for two slice levels of one of the 
cases, but I will send that later when I have a correlated screen dump +/- 
overlay.

Original comment by alexisan...@gmail.com on 29 Nov 2010 at 1:38

Attachments:

GoogleCodeExporter commented 9 years ago 
Andrew,

Just to double check, 70Gy is the correct Rx dose?

Roy

Original comment by roy.coding@gmail.com on 29 Nov 2010 at 7:59

GoogleCodeExporter commented 9 years ago 
correct, 7000cGy

The display is not right, here is an accurate pixellated dose pattern and 
corresponding slice, with overlay. High dose is OK but the 80% is wrong.

Original comment by alexisan...@gmail.com on 29 Nov 2010 at 12:52

Attachments:

GoogleCodeExporter commented 9 years ago 
I've been looking at the isodose lines and I think the issue may be with how we 
draw the lines rather than how we calculate them, though I'm not 100% certain 
yet. Plotting the dose data determined with the same methods as we use in 
dicompyler looks like the 80% lines miss the cord (i.e. not a dicom data 
problem).

Adit understands the isodose drawing code better than I do, so he will probably 
have a better chance at fixing this when he get's resuscitated after his next 
exam.

Original comment by roy.coding@gmail.com on 30 Nov 2010 at 11:33

Attachments:

GoogleCodeExporter commented 9 years ago 
In terms of correlating pictures and plans, it might be useful if you could 
nominate in the name which CT slice the images/dose come from so that I do a 
visual check with the original plan as seen on Pinnacle.

Once again, I am flabbergasted with your work, and if we meet at conference/s, 
beers and wine and food are on me.

Original comment by alexisan...@gmail.com on 30 Nov 2010 at 2:23

GoogleCodeExporter commented 9 years ago 
The dosemap I posted was from dose slice 46 (index = 45). That corresponds to a 
patient z position of about -757.29mm, which is closest to CT slice 119 (z = 
-758).

Just for reference, the isodose contours I plotted above are the 70% and 80% Rx 
isodoses.

Original comment by roy.coding@gmail.com on 1 Dec 2010 at 9:15

GoogleCodeExporter commented 9 years ago 
This issue was updated by r9da0f34cf2
This update has infinitely better contour generation with the added benefit of 
speed since the matplotlib backend is written in C.
The isodoses properly show multiple contours per isodose line and will respect 
holes in the particular curve.
The new curves are not as smooth as the curves generated by the previous 
method, but will be addressed in Issue 29.

Compare the attached screenshot to the one in comment 39.

Original comment by bastula on 10 Dec 2010 at 5:21

Attachments:

GoogleCodeExporter commented 9 years ago 
This should be addressed by r2b14df57ebb8 as the DVHs are now calculated 
independently. Please verify if the DVHs are correct with respect to your 
treatment planning system.

Original comment by bastula on 20 May 2011 at 3:48