Open GoogleCodeExporter opened 9 years ago
On a different machine, Windows 7 with more physical memory, the patient's
files opened, but when I maximized the window, I got the following fatal error:
Platform information:
System: Windows
Version: ('7', '6.1.7600', '', 'Multiprocessor Free')
Python Version: 2.6.6
dicompyler Version: 0.4.1-1
dicompyler.dvhcalc: DEBUG: Calculating DVH of 125 lungs
dicompyler.dvhcalc: DEBUG: Calculating DVH of 126 breast
dicompyler.dvhcalc: DEBUG: Calculating DVH of 127 skin
dicompyler.dvhcalc: DEBUG: Calculating DVH of 128 50%IDLpt
dicompyler: ERROR: Unhandled exception: Traceback (most recent call last):
File "P:\python\dicompyler-bdist\dist\baseplugins\2dview.py", line 611, in OnMouseMotion
File "P:\python\dicompyler-bdist\dist\baseplugins\2dview.py", line 626, in OnLeftIsDown
TypeError: unsupported operand type(s) for -: 'tuple' and 'Point'
Original comment by phill...@gmail.com
on 3 Oct 2012 at 4:39
I think the error above(second post) is relating to a mouse action in the
2dview.py too soon after changing the drawing state.
This same tuple/Point error used to occur, with the exe only, when attempting
to open a patient and double clicking the series in the tree view rather than
hitting the select button.
I think this might be the case when the 2dview is being redrawn for the
maximized mode. Could you try to hit ALT+SPACE to bring up the windows menu and
then press X to select maximize. But you will want to make sure the mouse is
NOT over the 2dview, so place it down in the start menu to prevent this on
maximize. That should prevent the tuple error and crash.
Original comment by lstrd...@gmail.com
on 4 Oct 2012 at 12:25
Hi Phil,
lstrdean is correct regarding the mouse action in the 2D view. This was
resolved in Issue 62.
Regarding the first issue, I have never seen a memory issue before, but granted
I have not tried a large RT Dose dataset. This may be specific to accessing the
dose grid via NumPy via pydicom. I will need to investigate what is the root
cause, as this may be something that may have to be corrected in an upstream
library.
Thanks for the report.
Original comment by bastula
on 4 Oct 2012 at 3:25
Update: After I adjusted my mouse movement habits, as instructed, I was able
to read the RT Dose (and other) files on my Windows 7 workstation. It has 8 GB
of memory, but dicompyler only used about 950 MB of memory. I was unable to
open the files on my Windows XP workstation, which has less but plenty of
memory. Dicompyler only used a few hundred MB of memory before crashing.
Phil
Original comment by phill...@gmail.com
on 5 Oct 2012 at 1:12
Might be able to quickly fix the memory error if the Numpy arrays are split
into multiple ones, any way to prevent a massive element wise operation. It
could be a problem with copying an over sized array. This memory error is a
pain with 32bit Numpy.
Phil, if you are handy with running Python I believe you can download a newer
version of Dicompyler which would include the mouse moving fix. However this
shouldn't affect the memory limit.
Also, I have worked with oversized RTDose files in the past. However my files
were created from a simulation system which included too much precision in the
decimals in printing. After I reduced this, the dose file was reduced my
hundreds of MB.
Original comment by lstrd...@gmail.com
on 5 Oct 2012 at 4:06
Original issue reported on code.google.com by
phill...@gmail.com
on 3 Oct 2012 at 1:31