Closed FAHOoms closed 1 year ago
Hi, we recently discovered a bug in SEPIA that incorrectly rescale the phase image if the data is in range [-pi , pi] with the rescale slope in the NIfTI header not equal to 1 (e.g. phase data converted from Philips scanner). Can you confirm if it is your case that the original phase image produced by the conversion tool has a dynamic range from -pi to pi, while the one output from SEPIA (i.e., prefix_part-phase_rad.nii.gz) has a narrower dynamic range (something like between -2.x and 2.x)?
Hi Kwok and FAHOoms, I remember that I had the same issue that phase unwrapping didn't use to work after converting dicom files (from Philips scanner) to nifti and using that in the sepia tool. As you were mentioning Kwok, the resulting rescaled phase by sepia was in the range of (-3.14, 2.277). I used the following trick to address the problem of incorrect rescaling: the last lines of DICOM2Phase mfile:
% scale to true value of nifti file dicomPhaseRescale = (dicomPhasescaleSlope) + scaleIntercept ; % scale the full range to [-pi,pi) % phase = (dicomPhaseRescale-newMin) / fullRange 2*pi - pi; % this line should be commented phase = dicomPhaseRescale; % this line should be added instead end
Also in the SepiaIOWrapper mfile, for the previous version (v0.8.1): %%%%%% Step 4: Basic correction % 4.1: check whether phase data contains DICOM values or wrapped phase value % if max(fieldMap(:))>pi || min(fieldMap(:))<-pi % this line should be corrected, 3.14 and -3.14 instead of -pi and pi if max(fieldMap(:))>3.15 || min(fieldMap(:))<-3.15 % use this line instead
Hi Kwok and FAHOoms, I remember that I had the same issue that phase unwrapping didn't use to work after converting dicom files (from Philips scanner) to nifti and using that in the sepia tool. As you were mentioning Kwok, the resulting rescaled phase by sepia was in the range of (-3.14, 2.277). I used the following trick to address the problem of incorrect rescaling: the last lines of DICOM2Phase mfile:
% scale to true value of nifti file dicomPhaseRescale = (dicomPhase_scaleSlope) + scaleIntercept ; % scale the full range to [-pi,pi) % phase = (dicomPhaseRescale-newMin) / fullRange * 2_pi - pi; % this line should be commented phase = dicomPhaseRescale; % this line should be added instead end
Also in the SepiaIOWrapper mfile, for the previous version (v0.8.1): %%%%%% Step 4: Basic correction % 4.1: check whether phase data contains DICOM values or wrapped phase value % if max(fieldMap(:))>pi || min(fieldMap(:))<-pi % this line should be corrected, 3.14 and -3.14 instead of -pi and pi if max(fieldMap(:))>3.15 || min(fieldMap(:))<-3.15 % use this line instead
Thanks Zahra for picking this up. This issue should also be solved in the next SEPIA update (v1.0.1).
We encountered some weird (phase unwrapping looking) artefacts in our QSM maps. These artefacts came from the Phase data file after conversion with the dicom2nifti conversion tool (as proposed in the sepia documentation), as it was not in the -pi to pi range. The reader appears to not cope well with that data format from a Philips scanner.