Hi,
As some of you will know, due to an interesting issue [0] caused by GE
installing an MRI scanner update, we have been having some problems with
transferring and processing MRI data recently. Because GE (despite
having admitted that this is their fault) are unable to fix this in a
timely manner, we've now managed to work around it in house and have
processed the backlog of data.
Everything up until last week has now been processed and uploaded and
last weeks' scans will be processed by the end of today.
Apologies for the delay but this came out of nowhere and even diagnosing
the problem took quite a bit of time.
If anybody thinks that scans they have performed since the start of the
year have not been processed, can you please send an email to
mri-support(a)ynic.york.ac.uk with details and we'll look into it.
Cheers,
Mark
[0] For Those Who Care About Technical Details
The executive summary is that they've changed the two values which
represent the Minimum (0028,0108) and Maximum (0028,0109) pixel values
in the image from 16 bit signed to 16 bit unsigned. The data which is
exported is still 16 bit signed and so this change makes absolutely no
sense whatsoever. Quite a bit of DICOM code I've looked at will cope
with either US or SS for these values but expects them to be consistent
with the actual data (which makes sense, if you're expressing a minimum
or maximum, it should be done using the same data type as the data).
A full dissection of the problem follows:
Old DICOM Image (selected tags only):
(0028,0103) US 1 # 2, 1 PixelRepresentation
(0028,0106) SS 0 # 2, 1 SmallestImagePixelValue
(0028,0107) SS 275 # 2, 1 LargestImagePixelValue
New DICOM Image (selected tags only):
(0028,0103) US 1 # 2, 1 PixelRepresentation
(0028,0106) US 0 # 2, 1 SmallestImagePixelValue
(0028,0107) US 2211 # 2, 1 LargestImagePixelValue
As you can se from the second column, the two bottom tags have changed
their Value Representation from SS (Signed Short) to US (Unsigned Short).
I've included the tag (0028,0103) because it explains how the actual
pixel data is to be interpreted. MR is fixed at 16 bits which leaves
two options: signed (2's complement) and unsigned.
To quote from the DICOM Standard:
Pixel Representation (0028, 0103): Data representation of the pixel
samples. Each sample shall have the same pixel representation.
Enumerated values:
0000H = unsigned integer
0001H = 2's complement
So, the data is still written as signed, whilst the min and max values
are written as unsigned. This is, at least in spirit if not letter, a violation
of the DICOM standard.
Note that although I state that according to the DICOM spec, MR is fixed at
16 bits, the interpretation of those 16 bits isn't fixed. See the tags
BitsStored, BitsAllocated and HighBit if you're interested. (In practice,
this is usually fixed for MR at 16, 16 and 15 respectively).
The fix is to read the value out of the file and hack the relevant VRs back
to being a signed integer instead of an unsigned one. The interesting
thing is that images processed with Clariview (e.g. the YNiC Structurals
which have FL_E in them) still use the signed value. So not only are GE
wrong, they're inconsistently wrong too.
--
Mark Hymers
York Neuroimaging Centre