-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Philips PAR/REC failure - negative slice gap? #273
Comments
@baxpr the issue is clearly with the PAR/REC files. As you note, viewing the PAR header with a text editor reveals
dcm2niix always assumes the header is truthful. I have submitted a simple kludge that should fix your issue: it measures the distance between slices using the slice position columns. If there is a discrepancy between the slice thickness + gap versus what is computed using slice position it will generate a warning and use the latter. My main concern is there may be unintended consequences. The slice position is provided with low precision. While I estimate across all slices, there still may be variation between what is reported by slice thickness + slice gap. On the other hand, I am not sure the slice thickness + slice gap tags are reported with much precision either. Test this heavily close this issue if you are comfortable with this solution. |
Sounds good to me - thanks for taking a look. |
Hi Negative Slice gaps usually come about when the scan is collected with "Over Contiguous Slices" as an option. In this case the data for each slice comes from a region larger than the interslice distance and so they overlap in the slice direction leading to a negative gap. However this would not be consistent with the slice thickness reported above. However I am not expecting a difference between the XML and PAR files in this case. So could @baxpr please email me separately and share the protocol/examcard and release and I'll look into it. Matthew |
* tag 'v1.0.20190410': (52 commits) Update dcm_qa submodule. Prevent MSVC compilation warnings Siemens PASL 3D BIDS tags (http://adni.loni.usc.edu/wp-content/uploads/2010/05/ADNI3_Basic_Siemens_Skyra_E11.pdf) Reduce Microsoft Visual Studio 14 warnings (rordenlab#288) Use fgets not getline (rordenlab#288) Fixes (rordenlab#286; rordenlab#287) Added missing space (coding standard). Supported dicom tag Accession Number (0008,0050). Struct TDICOMdata extended with accessionNumber property, modified dicom loader and supported exporting accession number into json file and using it as filename with %g modifier. Terminate when corrupted DICOM detected (rordenlab#283) Keep more characters for institution address (VR is ST) "dcm2niix -v" returns version (rordenlab#280) NRRD export supports oldmin/oldmax (http://teem.sourceforge.net/nrrd/format.html#oldmin) Assume 1.2.840.10008.1.2 if transfer syntax is empty Option to modify overwrite behavior (rordenlab#276) XA11 classic DICOM uses private tags for DWI (rordenlab#274) Detect Philips when manufacturer (0008,0070) has been erased (rordenlab#267) Detect discrepancies in PAR/REC slice thicknesses (rordenlab#273) New "-x i" option (https://www.nitrc.org/forum/forum.php?thread_id=9324&forum_id=4703) bvecs for Philips DWI using 0019,10bb, 0019,10bc Adjust negative MosaicRefAcqTimes (rordenlab#271) ...
@neurolabusc not sure if you're trying to stay on top of PAR/REC stuff but I've got some new Philips PAR/RECs that the most recent release v1.0.20181125 can't handle. At first glance I'd guess it's due to a negative value in the slice gap field. I can provide an example if you like. The PAR file specifies "gap -2.5". The XML file specifies "SliceGap 0.0". So there may be some issue upstream.
dicm2nii does work with these files, so there is an alternative.
The text was updated successfully, but these errors were encountered: