dcm2mnc can't read DICOM fields with OB value representation

[ajwood]

I've got an fMRI dicom series from a GE scanner that dcm2mnc can't convert correctly. I've narrowed it down to a problem reading the "locations in acquisition" field (0021,104f). In this dicom, this field's Value Representation is OB, so dcm2mnc ends up reading a 0; I know it's actually a signed short, and its value is 35.

My first reaction was to conclude that this is broken dicom data, but I have a Nifti converter that does the right thing with it. I'm wondering about ways to make dcm2mnc work with this data: 1) figure out how to tell dcm2mnc's dicom parser that (0021,104f) is supposed to be a signed short. Is this a generic solution though? Maybe sometimes this will get encoded as another type? 2) somehow get this information another way; for example, should we get this value by looking across all the dicoms in this series, and look for the number of unique values for slice location (0020,1041)?

[ajwood]

I ran this dicom through dciodvfy (http://www.dclunie.com/dicom3tools/dciodvfy.html), and it picked up on the OB fields violating the dicom dictionary, and correctly pointed out that this one should be SS. I don't really understand how a dicom dictionary can describe a private tag like this, but perhaps dcm2mnc should adopt the dictionary for use on OB values?

[andrewjanke]

If it were me, I'd be writing something dodgy (sorry, "agile") in Perl using either the DICOM:: Perl Module or system calls to dcmodify to sort out your input dicom data...

FWIW, I find it common to have to special case DICOM conversions/reads when you take data from multiple places. dcmdump is invaluable in these cases.

a

On 19 October 2017 at 02:07, Andrew Wood notifications@github.com wrote:

I ran this dicom through dciodvfy (http://www.dclunie.com/ dicom3tools/dciodvfy.html), and it picked up on the OB fields violating the dicom dictionary, and correctly pointed out that this one should be SS. I don't really understand how a dicom dictionary can describe a private tag like this, but perhaps dcm2mnc should adopt the dictionary for use on OB values?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BIC-MNI/minc-tools/issues/70#issuecomment-337642661, or mute the thread https://github.com/notifications/unsubscribe-auth/AATwijgp57NZRapX6n1g3Wj6V0F3FHQ0ks5stiI4gaJpZM4P926m .

[ajwood]

I haven't been able to come up with a dcmdump call that actually reads this field correctly though:

# Read from the bad series
$ dcmdump +P 0021,104f ./bad/001
(0021,104f) OB 23\00                                    #   2, 1 LocationsInAcquisition

# Read from a good series
$ dcmdump +P 0021,104f ./good/001
(0021,104f) SS 35                                       #   2, 1 LocationsInAcquisition

So I'm not sure how I could write the dodgy wrapper, since I'm not sure what the true value is. Of course in this case I know it's supposed to be 35, but shouldn't there be a way to solve this in a generic way?

[zijdenbos]

I asked David Clunie this questions; see below for his response. I would say that it would make sense for dcm2mnc to incorporate a dictionary fallback for these value representations?

From David Clunie:"The use of OB for private data elements usually happens because:

• the data was transmitted at some point using the Implicit VR Transfer Syntax, and

• the receiving system did not know the private VRs to use when storing to a file as Explicit VR, and

• the receiving system used the OB VR instead of the UN VR intended for this purpose

Ideally the site would use the happy path that gives the manufacturer-intended VR rather than OB, but it is hard to argue that they are "wrong".

I often do what you suggest, which that if a "better" VR is known to the application, e.g., from a reliable private data dictionary, and the explicit VR is UN or OB, then I change the VR. This rarely has undesirable consequences.

Many of us who build tool kits have collected extensive data dictionaries of private data elements either from Conformance Statements or images encountered in the field, and dciodvfy makes use of mine."

On Wed, Oct 18, 2017 at 12:38 PM, Andrew Wood notifications@github.com wrote:

I haven't been able to come up with a dcmdump call that actually reads this field correctly though:

Read from the bad series

$ dcmdump +P 0021,104f ./bad/001 (0021,104f) OB 23\00 # 2, 1 LocationsInAcquisition

Read from a good series

$ dcmdump +P 0021,104f ./good/001 (0021,104f) SS 35 # 2 https://maps.google.com/?q=104f)+SS+35+%23+2&entry=gmail&source=g, 1 LocationsInAcquisition

So I'm not sure how I could write the dodgy wrapper, since I'm not sure what the true value is.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BIC-MNI/minc-tools/issues/70#issuecomment-337651696, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_r-D3Y8QfMmgJqrW2Ae4Vjmkj8xHZtks5stilugaJpZM4P926m .