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

Alex Zijdenbos alex at bic.mni.mcgill.ca
Wed Jul 28 10:53:40 EDT 2010


On Wed, Jul 28, 2010 at 8:54 AM, Andrew Janke <a.janke at gmail.com> wrote:
> Hi Alex,
>
>> 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?
>
> Well I have converted such data (ASL to be exact) of a Siemens 1.5, 3T
> and 4T machine so am somewhat loathe to mess with dcm2mnc...

So these data you speak of were anisotropic in-plane?

> Being a
> Bruker and a 7T if this is some custom acquisition sequence be sure
> that you haven't mixed the phase directions about or something. Last I
> looked the Bruker pulse programming language lets you do pretty much
> as you want.
>
> Is the data you have from a standard sequence or a custom one?

It is custom, but derived from a standard Bruker sequence and modified
only in ways that do not affect the phase/readout directions.

By the way, the same anisotropic dicom slices do render properly with
other tools (e.g., xmedcon). So my vote is still that the dicom is in
fact good, and this is in fact a bug in dcm2mnc. I suspect the
interpretation of "rows" and "columns" was mixed up.

-- A


More information about the MINC-users mailing list