Open GoogleCodeExporter opened 9 years ago
The first traceback seems like an issue if the RT plan is missing from the data
set. There are conditionals that should catch that. I wonder why it's failing.
I can look into that issue after you get a chance to anonymize the data.
Regarding the second traceback, I deleted the preferences.txt in my
~/.dicompyler folder, only loaded CTs and the RT structure file from the
testdata, using hg r730e082a798b and it seems to work fine. I also loaded the
exported data back in and it looks ok.
Give it a shot with the testdata and see if that works.
Original comment by bastula
on 1 May 2011 at 8:41
The first traceback is probably due to RT plan part could not be loaded:
HIT-Test_12C_01_Mimi.RTIMAGE
.Spezial_01HIT_BPL_.6.4.2011.01.21.14.00.05.757.75851190.IMA is a RT Image
Storage file and is not currently supported.
deleting the preferences.txt helped, I could read different DICOM test files
and export these. Going back to the original file then breaks it again,
apparently it is linked with those non-supported files.
Loading those RT Image Storage files manually with pydicom works alright.
Original comment by niels.bassler
on 1 May 2011 at 8:53
Do you mean going back to the original preferences.txt or going back to the
original DICOM data? Is it possible for you to send a copy of the data that
doesn't work (via dropbox or other means)?
Currently, I have not enabled support for RT Images, but eventually dicompyler
will support all DICOM formats. It's just a matter of adding a line in dicomgui.
The only issue is that a plugin needs to be written to display those particular
formats. In the case of RT Images, the 2D viewer can easily show them; I just
need a way of figuring out whether the user wants to see the CT data, RT
images, or both. As of now, the main focus is on CT images so the 2D viewer
assumes it is getting serial slices.
Original comment by bastula
on 1 May 2011 at 9:04
I deleted preferences.txt AND go back to the original DICOM test data, all was
ok then. About the dataset, I just have to check the permission first, then I
will make it available and let you know.
Regarding the viewing: In PyTRiP I added a box where one could select which
data should be viewed.
http://aptg-trac.phys.au.dk/pytrip/attachment/wiki/Screenshots/pytrip_rev67_1.pn
g
(Note the tabbed panel at the bottom, you might need something similar, sooner
or you will run out of space...)
Original comment by niels.bassler
on 1 May 2011 at 9:16
Got the OK to distribute the DICOM RT Ion sample files (thanks to O. Jäkel
from HIT). I uploaded a tarball here:
http://neptun.phys.au.dk/~bassler/DKFZ/DICOM/
apparently the error messages from the non-supported dose plans seem to provoke
the aforementioned DeadObject error.
Original comment by niels.bassler
on 3 May 2011 at 8:51
Hi Niels,
Thanks for uploading the data. I have downloaded a copy and I will try to take
a look within the next week or so.
Adit
Original comment by bastula
on 12 May 2011 at 3:13
RT Ion Plan is now supported as of r7f6368d37bb6 and I can anonymize the data
set you provided and also read it back into dicompyler.
The dose data still cannot be displayed in the 2D view, as it seems that each
of them are fraction objects. If this is correct, then in order to display the
dose properly, all the dose objects need to be summed together. However, the
referenced fractions all point to Fraction #1.
I think this now is a more general issue of RT Dose format than RT Ion, so I am
changing the issue summary.
Original comment by bastula
on 19 Oct 2011 at 4:13
Original issue reported on code.google.com by
niels.bassler
on 1 May 2011 at 8:12