RTDOSE and PixelRepresentation = 1

[Rickard Cronholm]

I'm trying to manipulate a RTDOSE file as to the get sign on the pixel values. According to nema this should be possible by setting the PixelRepresentation to 0001H (as oppose to the default 0000H) if and only if the DoseType is 'ERROR'. 

This works and is handled correctly in pydicom (version 0.9.8). However, when importing to my TPS (tried Eclipse as well as Oncentra MasterPlan) the RTDOSE is rejected. Eclipse states that the Pixel Representation is invalid. 

I found this blogpost on PixelData that mentiones the following;

Pixel Representation (0028,0103) is either unsigned (0) or signed (1). The default is unsigned. There's an anecdotal issue here with VR codes of US and SS and this attribute because when it is set to signed then all the attributes of group 0028 should be encoded as Signed Shorts (SS) and when it's unsigned they should be unsigned (US) too.

These changes can be made to a dataset in pydicom, but I discovered when writing and rereading the file in pydicom the VRs are changed back to US. Do I need to do something special in order to write with the current VR type?

[Rob]

 

If I remember correctly, PyDICOM has an issue with settings new values of tags; pydicom does not cascade properly when the new value is set in an object oriented way.

 

Maybe you can try:

- read the tag value

- update the VR type

- reset the tag value

 

 

[Darcy Mason]

Hi Rickard,

Can you walk us through what exactly you have set?  I toyed with this very briefly (without trying to load into a TPS).  Here is what I did after loading the dataset (pixel_array dtype was uint32 before changing anything):

>>> pix2 = ds.pixel_array.astype(numpy.int32)

>>> ds.PixelData = pix2.tostring()

Then you could set ds.PixelRepresentation and DoseType etc. and save_as().  When I wrote this and read it back in, I still get dtype of int32 for pixel_array.

This was for an implicit VR file (rtdose.dcm in pydicom's test files).

Darcy

[Rickard Cronholm]

I'm not sure I understand what you mean by 'reset the tag value'. Can you please demonstrate with an example?

[Rickard Cronholm]

I'm having problems loading the rtdose.dcm from the pydicom's test files, so this is another RTDOSE file (also created from a TPS).
The lines below is what I strive to do (in this example I've left the pixel_array and PixelData untouched although in a real example I'd modify the values of those).

>>> dcm = dicom.read_file('MCQA/data_reference.dcm')
>>> dcm.data_element('PixelRepresentation')
(0028, 0103) Pixel Representation                US: 0
>>> dcm.data_element('PixelRepresentation').VR = 'SS'
>>> dcm.data_element('PixelRepresentation').value = 1
>>> dcm.data_element('PixelRepresentation')
(0028, 0103) Pixel Representation                SS: 1

>>> dcm.save_as('newRD.dcm')
>>> dcm_new = dicom.read_file('newRD.dcm')
>>> dcm_new.data_element('PixelRepresentation')
(0028, 0103) Pixel Representation                US: 1

So, the value is updated correctly, but the VR type is not. Can you please elaborate on the term 'inplicit VR file'?

[Darcy Mason]

Implicit VR files do not store the VR of any of the data elements; they are looked up in the dicom dictionary by the program reading the dicom information.  You probably have an implicit VR file (check ds.is_implicit_VR) and that is why the VR change does not stick -- when read back in, pydicom would go to the dicom dictionary and look up the VR there, which would always be US, because PixelRepresentation only takes values 0 or 1.

However, you don't need to change the VR of PixelRepresentation, just its value, to 1.  I think the other key thing is to change the pixel numpy data type as in my last reply, and the DoseType, and perhaps LargestImagePixelValue, if that exists (maybe its not used for dose files, I'm not sure).

I don't know still if those changes will make it readable in the TPS.  Do you have examples of other "ERROR" files that the TPSs can read?  They may not accept them anyway.

[Rickard Cronholm]

Thanks for the clarification. The file in question is in deed implicit VR. There is not a LargestImagePixelValue in RT Dose. Our TPS (Eclipse) imports files with DoseType=ERROR just fine. It does, however, reject RT Dose files with PixelRepresentation = 1. I disagree with your suggestion of changing the type of pixel_array. It should be unsigned, negative values (signs) are handled by the HighBit when PixelRepresentation = 1. I tested in MATLAB and it handles it correctly. As does pydicom. These steps will demonstrate it:

ds = dicom.read_file(filename)

dose = ds.pixel_array * float(ds.DoseGridScaling)

dose[i,j,k] = -dose[i,j,k]

ds.PixelRepresentation = 1

ds.PixelData = (dose/float(ds.DoseGridScaling)).astype('uint32').tostring()

ds.save_as(newfile)

ds = dicom.read_file(newfile)

dose = ds.pixel_array * float(ds.DoseGridScaling)

dose[i,j,k] 

A negative value should be returned here.

If PixelRepresentation is set to 0, a positive (large) number will be returned.

It appears as the problem lies with the TPS. A sidenote is that pydicom allows PixelRepresentation to equal 1 even if DoseType is Physical, which it should not according to my understanding of the DICOM standard. 

--
You received this message because you are subscribed to a topic in the Google Groups "pydicom" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pydicom/09vLtjWvrW0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pydicom+u...@googlegroups.com.
To post to this group, send email to pyd...@googlegroups.com.
Visit this group at https://groups.google.com/group/pydicom.
For more options, visit https://groups.google.com/d/optout.