Problem loading binary(?) data into DICOM data tree

[GoogleCodeExporter]

Using change set b2db1399c5 (26 Nov. 2010).

I'm getting an error when I load some images in the treeview plugin if they 
contain LargestImagePixelValue or SmallestImagePixelValue entries. It appears 
that these values are stored as binary data (not quite sure), but treeview.py 
tries to read them as unicode.

Here's the error messages (for different CT images):

.../baseplugins/treeview.py", line 178, in AddItemTree
    self.tlcTreeView.SetItemText(item, unicode(data_element.value), 1)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: invalid 
data

.../baseplugins/treeview.py", line 178, in AddItemTree
    self.tlcTreeView.SetItemText(item, unicode(data_element.value), 1)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xb2 in position 0: 
unexpected code byte

The code throwing the error is found in AddItemTree in treeview.py. We could 
make exceptions specifically for these tags, *PixelValue, but a more general 
solution sounds better.

As a side note, I'm not sure what the first else is doing in AddItemTree:

        else:
            # Account for unicode or string values
            if isinstance(data_element.value, unicode):
                item = self.tlcTreeView.AppendItem(parent, text=unicode(data_element.name))
            else:
                item = self.tlcTreeView.AppendItem(parent, text=str(data_element.name)

It seems to be testing the "value", but acting on the "name".

Original issue reported on code.google.com by roy.coding@gmail.com on 2 Dec 2010 at 7:35

[GoogleCodeExporter]

p.s. I get these errors with some of the CT's in the AAM Pinnacle series.

Original comment by roy.coding@gmail.com on 2 Dec 2010 at 7:37

[GoogleCodeExporter]

Just a note: The binary data can be read using the struct module.

If for example the LargestImagePixelValue = '\xb2\x0b', as with image 64 in the 
AAM series, you can use:

img64 = dicom.read_file('ct.64.dcm')
struct.unpack('h', img64.LargestImagePixelValue)

That returns (2994,) where 'h' means short integer.

We may need some code to check the data type, since 'h' may only work here (I 
haven't looked at DICOM docs or other image files yet).

Original comment by roy.coding@gmail.com on 5 Dec 2010 at 8:18

[GoogleCodeExporter]

This doesn't give an error anymore with the latest changeset: r599ab350df91. 
However, as you stated, the value still needs to be decoded to a short or an 
unsigned short.

I am curious if this should be determined by looking at some combination of 
High Bit, Bits Allocated and Bits stored to see whether it should be a short or 
unsigned short.

Some more investigation into the DICOM documentation would be required here.

Original comment by bastula on 25 Jan 2012 at 3:00