I would never suggest changing original DICOM data files but instead recommend tweaking the code to adjust for unexpected values in the data.


-----Original Message-----
From: [log in to unmask] on behalf of Julien Dubois
Sent: Tue 1/20/2009 5:23 PM
To: Kathy L Pearson
Cc: [log in to unmask]
Subject: Re: [SPM] Dicom import bug: one slice singled out from a structural scan


I have tracked the problem down: for that one slice, the EchoTime
field in the dicomheader as well as the EchoNumber field differ from
all the other slices. I saw that EchoNumber is used for sorting in
spm_dicom_convert.m, hence the problem. I am assuming that I should
change the values of these two fields in the headers of the singled
out slice, using dicomread/dicomwrite/dicominfo from the Matlab image

- Julien

On Tue, Jan 20, 2009 at 8:11 AM, Kathy Pearson <[log in to unmask]> wrote:
> Julien,
> I have seen this problem when values of DICOM header variables unexpectedly
> differ between scan images that really belong to the same series.  The
> differences might not be caught by the tolerances of 1e-5.  To avoid this
> problem, in SPM5 I edited spm_dicom_convert.m to change the tolerances
> around line 262 in this MATLAB statement:
>        match = hdr{i}.SeriesNumber     == vol{j}{1}.SeriesNumber &&...
>        hdr{i}.Rows                             == vol{j}{1}.Rows &&...
>        hdr{i}.Columns                  == vol{j}{1}.Columns &&...
>        sum((hdr{i}.ImageOrientationPatient -
> vol{j}{1}.ImageOrientationPatient).^2)<1e-5 &&...
>        sum((hdr{i}.PixelSpacing - vol{j}{1}.PixelSpacing).^2)<1e-5 && ...
>        identical_ice_dims && dist2<1e-3;
> You can inspect your DICOM header variables for your 1-image volume DICOM
> and one from your 33-image volume DICOM to see if any of these variable are
> different in any way.  It depends on your input as to whether you wish to
> change the 1e-5 setting here.
> Also, you may want comment out around line 242 the "dist2 = 0" line:
>        dist2  = sum((xy1-xy2).^2);
>        % This line is a fudge because of some problematic data that Bogdan,
>        % Cynthia and Stefan were trying to convert.  I hope it won't cause
>        % problems for others -JA
>        dist2 = 0;
> If you do the math for dist2 and find this is needed for your images, then
> the 1e-3 tolerance for dist2 above can be reviewed, too.
> If you are running SPM2 instead, then there are no tolerances at all in the
> code looking for a match in the PixelSpacing and ImageOrientationPatient
> fields -- strict equivalence is required -- so you may want to introduce a
> difference tolerance in the similar lines of "match" code in SPM2's
> spm_dicom_convert.m  Also, in SPM2, the dist2 variable is not reset to zero,
> and its tolerance is 1e-5 instead of SPM5's 1e-3.  The SPM2 strict
> equivalence caused trouble for me when two scans had differences in DICOM
> header variables in the 8th decimal place.
> Kathy Pearson
> UAB Psychology
> -----Original Message-----
> From: SPM (Statistical Parametric Mapping) [mailto:[log in to unmask]] On
> Behalf Of Julien Dubois
> Sent: Sunday, January 18, 2009 7:39 AM
> To: [log in to unmask]
> Subject: [SPM] Dicom import bug: one slice singled out from a structural
> scan
> Hi SPM-ers
> I have collected a B0 field map, with 34 slices. I have 34
> corresponding dicom images, which all have the same AcquisitionNumber
> and SeriesNumber, with the InstanceNumber ranging from 1 to 34. When
> running the Dicom Import utility on this series, SPM outputs two final
> volumes: a 33-slice volume and a 1-slice volume (it singles out the
> dicom image with InstanceNumber 28). Has anyone encountered such a
> problem? is it fixable (something to mess with in the dicom headers?)?
> Thank you very much if you can help.
> - Julien