From alex at bic.mni.mcgill.ca  Sun Dec  9 14:58:04 2007
From: alex at bic.mni.mcgill.ca (Alex Zijdenbos)
Date: Sun, 9 Dec 2007 14:58:04 -0500
Subject: [MINC-development] bug in dcm2mnc
Message-ID: <e758a6650712091158l41dcb63bld07c8a5214d3185b@mail.gmail.com>

Hi all,

[posting this wide as many may be affected]

I stumbled across a bug in dcm2mnc which mangles echo times. From dicom_read.c:

    gi_ptr->acq.echo_time =
        acr_find_double(group_list, ACR_Echo_time, -DBL_MAX);
    if (gi_ptr->acq.echo_time != -DBL_MAX)
        gi_ptr->acq.echo_time /= 1000.0;

    gi_ptr->acq.echo_time =
        acr_find_double(group_list, ACR_Echo_train_length, -DBL_MAX);
/*added echo train length ilana*/

That last one overwrites the just-gotten echo_time with
echo_train_length, and should have read read:

    gi_ptr->acq.echo_train_length =
        acr_find_double(group_list, ACR_Echo_train_length, -DBL_MAX);
/*added echo train length ilana*/

Ah... the dangers of cut-and-paste :)

I have fixed this and checked the fix into cvs. However, my guess is
that all minc files created with dcm2mnc since ilana's modification,
done in June this year, will have bad echo times. I suppose this only
affected the minc-2.0.14 release - Andrew?

-- Alex

From jharlap at bic.mni.mcgill.ca  Tue Dec 18 10:25:54 2007
From: jharlap at bic.mni.mcgill.ca (Jonathan Harlap)
Date: Tue, 18 Dec 2007 10:25:54 -0500
Subject: [MINC-development] another bug in dcm2mnc
Message-ID: <8FF53835-A24C-44CB-9CEA-A980D03AC3FA@bic.mni.mcgill.ca>

[possibly a repeat - last one went from the wrong address and thus may  
be rejected]

These two bugs seem to only affect dcm2mnc in minc 2.0.14.  Cross- 
posted as it belongs primarily in the development list but affects  
users of 2.0.14 and so should be known.

1) For reasons unknown the attribute acquisition comments was renamed  
to acquisition image_comments, which breaks consistency with old  
data.  It has been reverted back from whence it came.

2) All dicom_* groups were left out of the produced minc headers which  
may have seemed convenient to someone making the change but is rather  
inconvenient to anyone who expected those fields to be there, as it  
used to be.  These have been reverted, with the one change that  
attributes with length=0 are not added as it makes HDF complain and we  
can probably assume safely that an attribute with no content isn't  
particularly useful.  And yes, that's me making a judgement call about  
what might be useful to others - which is exactly what I'm railing  
against here, but I do so only because it avoids screenfuls of HDF  
warning messages.

Fixes are in CVS and will hopefully appear shortly in 2.0.15.

Cheers,
J