[MINC-users] dcm2mnc and (ir)regular spacing?

[Alex Zijdenbos]

Hm the plot thickens on this spacing issue. I went back to the
conversion, and found this in the conversion log:

WARNING: Coordinate spacing (4) differs from DICOM slice spacing (5)
 (perhaps you should consider the -usecoordinates option)
 Using 5 for the slice spacing value.

>From what I can gather, the acquisition actually has 4mm slice
thickness with 1mm gaps, bringing the (correct) slice spacing to 5mm.
However, the coordinate spacing shows 4mm. If I use dcm2mnc
-usecoordinates I get a volume with the header I previously posted;
i.e., with a zstep of 4mm and a list of positions, also 4mm apart, in
the data section of the header. Although that is internally
consistent, the brain comes out looking 'squashed'.

Without -usecoordinates, the resulting volume has a zstep of 5mm and
is visually correct (in register); however, it still has the same list
of zspace coordinates that are 4mm apart. Besides the fact that that
is internally inconsistent, whenever I resample the volume it
immediately comes out 'squashed' again, so I assume that mincresample
relies on the explicit list of coordinates.

So it seems that dcm2mnc cannot handle these DICOM data properly
somehow (or the DICOM itself is bad).

Is there a way to remove the list of zspace coordinates from the MINC
header (other than by turning the volume into a stack of slices and
re-assembling it again)?

Thanks,

-- A

On Sun, Jan 8, 2012 at 11:31 AM, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
> On Sun, Jan 8, 2012 at 11:09 AM, Andrew Janke <a.janke at gmail.com> wrote:
>> Hi Alex,
>>
>> On 7 January 2012 00:17, Alex Zijdenbos <zijdenbos at gmail.com> wrote:
>>> I am a bit puzzled by this MINC header:
>>>
>>> minc.hdr (http://cl.ly/1D0x0a3x002Y0w2O242U)
>>>
>>> specifically w/respect to the spacing along the time dimension. Towards the bottom of the header there is info for the time dimension; however, the time:spacing attribute is "regular". Shouldn't the time:spacing attribute be "irregular", given that the spacing is in fact not regular?
>>
>> My read of your header has time at a pretty constant 4s?
>
> For the most part yes; but there is at least one discontinuity in it,
> with a step of >86000s, no?
>
>> Steps also
>> can be ever so slightly different, currently defined here as 0.005:
>>
>>   https://github.com/andrewjanke/minc/blob/master/conversion/dcm2mnc/dicom_to_minc.h#L106
>>
>> And a dimension will still be called regular. The logic for this is here:
>>
>>   https://github.com/andrewjanke/minc/blob/master/conversion/dcm2mnc/minc_file.c#L182
>
> That all makes sense I guess; however, shouldn't there conceptually be
> agreement between the presence of the (ir)regular <dim>:spacing
> attribute value, and the presence of a (likely irregular) list of
> positions in the data section? In other words, if the spacing is
> judged to be regular, why would there still be an explicit list of
> positions in the header (the underlying question being, what do/should
> applications use)?
>
> Thanks,
>
> -- A