Open suever opened 9 years ago
From darcymason@gmail.com on February 15, 2011 19:23:41
I tried it on a few of the standard pydicom test files without getting an error. So, if you can provide a file, that would certainly help.
Status: Accepted
From DaniN...@gmail.com on February 16, 2011 02:16:08
Thanks for trying. So it is a file-specific thing. I attach a sample file with which I observe the problem. It should be a fairly standard GE MRI file.
Attachment: img_one.dcm
From rupert.k...@uni-tuebingen.de on October 25, 2011 09:24:38
I got this error too:
d_ds = copy.deepcopy( ds) File "/usr/lib64/python2.6/copy.py", line 189, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/usr/lib64/python2.6/copy.py", line 335, in _reconstruct y[key] = value File "/usr/local/lib/python2.6/site-packages/pydicom-0.9.5-py2.6.egg/dicom/dataset.py", line 497, in setitem data_element.private_creator = self[private_creator_tag].value AttributeError: 'RawDataElement' object has no attribute 'private_creator'
I have Siemens DICOM files with MR spectroscopy data (and a lot of private tags). My system: openSUSE 11.3, 64bit, Python 2.6.5, dicom.version '0.9.5'
It would be fine, if there is a solution for this error.
Best regards,
Rupert Kolb
From darcymason@gmail.com on October 26, 2011 17:30:52
It may take a while, but I am looking at converting RawDataElements immediately after reading, which should solve this and a few other issues.
From Suever@gmail.com on December 09, 2011 13:54:07
I came across a similar issue doing the following:
import dicom ds = dicom.ReadFile('image.dcm')
sub_dataset = ds.group_dataset(25)
Traceback (most recent call last):
File "
The error is due to the fact that group_dataset() and copy.deepcopy() both require the creation of a new dataset and then they copy over the data. For private fields, many times the data is a RawDataElement and therefore when you attempt copy it it fails due to the fact that the setitem method of data_element assumes that the input is a DataElement (has the private_creator function).
A temporary fix can be achieved by simply checking to see if it is a RawDataElement rather than a DataElement and if so, convert it using dicom.dataelem.DataElement_from_raw
I have attached a diff file (referencing 0.9.6 - Nov. 11, 2011) as well as the replacement dataset.py file
Using this fix, I was able to avoid both the crash stated above as well as my own.
Attachment: dataset.py.diff dataset.py.new
From darcymason@gmail.com on December 09, 2011 17:01:49
Suever, thanks for this. I've been holding off waiting on the bigger fix I mentioned, but I think it is time just to make it work for now. Your change does that nicely. Will push to the repository.
And since you mentioned the copy/deepcopy issue, I have some code in draft for that. In that case, I think the raw elements should be copied as is, to be true to python's usual behaviour for copy/deepcopy. Your change is compatible, as my copy code avoids calling setitem.
From darcymason@gmail.com on December 09, 2011 17:24:59
Pushed Suever's fix to repository ( revision 3dd6a7142207 ), but keeping the issue open to look into overall better handling of raw data elements (either immediate conversion after reading file, or copying them as is without invoking conversion to regular DataElement).
Status: Started
From DaniN...@gmail.com on February 15, 2011 03:42:08
What steps will reproduce the problem? C:\Python26\python.exe 2.6.5 ( r265 :79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)]
Traceback (most recent call last): File "", line 1, in
File "C:\Python26\lib\copy.py", line 189, in deepcopy
y = _reconstruct(x, rv, 1, memo)
File "C:\Python26\lib\copy.py", line 335, in _reconstruct
y[key] = value
File "C:\Python26\lib\site-packages\dicom\dataset.py", line 497, in setitem
data_element.private_creator = self[private_creator_tag].value
AttributeError: 'RawDataElement' object has no attribute 'private_creator' What is the expected output? What do you see instead? Expect no output but was hoping for a deep copy of the dataset.
Got above traceback instead. What version of the product are you using? >>> dicom.version
'0.9.5'
I get the same traceback when trying to use copy.copy() instead of copy.deepcopy(). The file that causes this is available if that helps.
Best regards, Dani Nanz
Original issue: http://code.google.com/p/pydicom/issues/detail?id=98