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@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.