[MINC-users] Another bug in dcm2mnc -> x/y step switch?

[Alex Zijdenbos]

Hello all,

I just stumbled across this issue again, which so far has not been
addressed in dcm2mc in cvs. Can anybody verify whether this is indeed
a bug in dcm2mnc, or a bug in the dicom that I get (from a Bruker 7T
animal scanner)? In other words, has anybody tried to convert dicom
data that is anisotropic in-plane, from some other scanner?

If indeed this is a bug in dcm2mnc, it would be good if it would be
fixed in the upcoming minc 2.1 release.

Thanks,

-- Alex

On Sun, Dec 9, 2007 at 11:23 PM, Alex Zijdenbos <alex at bic.mni.mcgill.ca> wrote:
> Hello all,
>
> I have been trying to solve another dicom-to-minc conversion problem,
> and that is that I have some data that are anisotropic in-plane
> (128x256), with step sizes 0.19 and 0.39 mm (the FoV is square).
> However, when converting this with dcm2mnc, the x- and y-step sizes
> are inverted, such that the resulting minc volume is, well rather
> squashed. In the DICOM data, I have:
>
> (0028, 0010) US      2: Rows                              = 128
> (0028, 0011) US      2: Columns                           = 256
> (0028, 0030) DS     18: PixelSpacing                      = 0.390625\0.1953125
>
> However, converting that with dcm2mnc, I get:
>
>    dimension name         length         step        start
>    --------------         ------         ----        -----
>    zspace                     29            1        -13.3
>    yspace                    128    -0.195312           25
>    xspace                    256    -0.390625           25
>
> Clearly the x-and y-steps are reversed.
>
> On lines 1417/18 of dicom_read.c:
>
>    steps[VCOLUMN] = psize[0];
>    steps[VROW] = psize[1];     /* anisotropic resolution? */
>
> I *think* that this is wrong, that the indices into psize should in
> fact be reversed. And sure enough, if I do that and reconvert my data,
> everything looks good...
>
> However, I was wondering if somebody more familiar than I am with
> dicom-to-minc conversions could verify this. Anybody else seen this?
> Most commonly people acquire data which is isotropic, or close to
> isotropic, in-plane, so it would not surprise me if it hasn't been
> noticed before - but there could also be something specific about the
> data that I have. If this is indeed a bug I'm happy to check the fix
> into cvs, but I'd rather be sure that it is a general problem.
>
> Thanks,
>
> -- Alex
>