[MINC-development] Unexpected value scaling with miget_real_value_hyperslab

[Rick Hoge]

I've been working on some code to load data from a MINC2 file into memory, and have encountered some puzzling behaviour.  The files I've been testing have been generated with dcm2mnc (minc-2.0.18) from Siemens DICOM files.  I'm running x86_64 binaries on OSX 10.6.  I'm using dcm2mnc without any flags other than the required input and output paths.

Here's the background:

First I run

dcm2mnc DICOM_Files/*.dcm ./

Next I run the program that reads the created MINC2 file -

miget_data_type(minc_volume, &mincDataType) says that the data in my MINC2 file (created as described above) is MI_TYPE_USHORT.

I set up the arrays 'starts' and 'counts', allocate an appropriately sized memory buffer, and call

miget_real_value_hyperslab(minc_volume, MI_TYPE_USHORT, starts, counts, buffer)

to copy the entire 4D dataset into my buffer.

I get the series as expected, however the unsigned shorts in the buffer appear to have been scaled so that the minimum and maximum values correspond respectively to 0 and USHRT_MAX.  I know the values in the file should be within the range 0 to 4095 since it comes from 12-bit DICOM - this is in fact the 'valid range' reported for the MINC2 file by mincinfo.  The true range of data values in my example file is actually 0 to 1006.

What is causing this scaling to happen?  I notice also that miget_slice_scaling_flag(minc_volume, &slice_scaling_flag) returns 1, so it appears that some kind of scaling has been applied.

I've tried using miget_real_value_hyperslab() but then the intensities of the different slices are individually remapped.

Creating MINC1 files from the same DICOM files with the same dcm2mnc binary and reading the values with miicv_get () returns the correct numeric values for the voxel data (i.e. the numbers match what I see in the DICOM files).

Finally I noticed that if I use

miget_real_value_hyperslab(minc_volume, MI_TYPE_FLOAT, starts, counts, buffer)

to fill a buffer with float values from the same file, I get close to the correct numeric voxel values.  However the values all include a non-zero decimal fraction component, so that a voxel with a true value of 327 comes out as 326.74.

At this point I'm not sure if this is a feature or a bug, but I'd be grateful for any suggestions on what is happening and how to recover the original values that were read from the DICOM file in a simple and robust way.

Thanks in advance!

Rick