PAR/REC support

[neurolabusc]

Ben Conrad has provided a very unusual PAR/REC file based on a work in progress MP2RAGE where dcm2niix refuses to convert the image. This image has two unusual properties:

1. The image_type_mr column for some slices is 4, while known image types are magnitude (0), real (1), imaginary (2), phase (3)
2. The scanning sequence column varies within a single PAR file. In all previously observed PAR/REC files the sequence is the same for the entire file. Typically, one can read the first portion of the header to determine if a column varies, for example Max. number of echoes : 2 allows you to expect two echos in the subsequent lower portion of the header. Unfortunately, the number of scanning sequences is not reported in the top of the header. This behavior frustrates rapid single pass converters like dcm2niix that were developed on the assumption that the top part of the header provides a road map for decoding the second part. The only robust solution is to switch to a two pass read that relies only on the lower portion of the header - at a substantial speed penalty for large datasets.

The development branch includes a new version (v1.0.20190112) with a kludge to handle the provided samples. It will intentionally mislabel type 4 images as "phase" to allow file name disambiguation from the magnitude images. It will correctly save the two image_type_mr as two separate volumes. This kludge will fail (with an error code) if there are more than two image_type_mr in the PAR file. So while this works with all known existing images, one could imagine implementations of the PAR format that break this. The new code will generate the following warnings to alert the user about these issues.

Warning: dcm2niix PAR is not actively supported (hint: use dicm2nii)
Warning: Unknown image type (4). Be aware the 'phase' image is of an unknown type.
Warning: 'scanning sequence' column varies within a single file. This behavior is not described at the top of the header.

I have little appetite to support the PAR/REC format. I do not have access to this format. It is a proprietary format that is not documented and therefore requires re-engineering. It is a format that has been and probably will be extended in unexpected ways by the vendor. While justified at the time it was developed, the one-pass approach used by dcm2niix is not easy to extend for the variations of this format now seen in the field. The current implementation disrupts rapid methods for decoding.

I would be happy to review pull requests from anyone who wants to develop and maintain a simpler, more robust, easier to extend but slower two-pass converter for dealing with these files. However, I would urge all Philips users to consider alternatives

1. While complicated, the DICOM format is at least a standard and is more appropriate for archival data.
2. Consider using Xiangrui Li's excellent dicm2nii instead of dcm2niix. His implementation supports unusual situations that were unknown when the dcm2niix algorithm was developed, like acquisitions that are interrupted mid-acquisition where slices are not stored sequentially.
3. Consider using Philips own PAR to NIfTI converter. I have heard from several users that modern variations of Philips output are not compatible with this software. However, since they broke their own format, they should be responsive to fixing their own tool to support their changes. You have purchased a professional product and you should expect professional service. While I have tried to support this, I no longer work with this hardware, I do not have documentation for this format and I have a lot of other responsibilities.

[drmclem]

Hi

There are a couple of possibilties - internaly we are not restricted to 4 types -
as a copy and paste these are possible values for the internal types on dicom private
tags 0x2005,0x1011 {"M","R","I","P","CR","T0","T1","T2", "RHO","SPECTRO","DERIVED",
"ADC","RCBV","RCBF","MTT","TTP","FA","EADC","B0","DELAY","MAXRELENH",
"RELENH","MAXENH","WASHIN","WASHOUT","BREVENH","AREACURV","ANATOMIC",
"T_TEST","STD_DEVIATION","PERFUSION","T2_STAR","R2","R2_STAR","W",
"IP","OP","F","SPARE1","SPARE2"}

So this could be actually a "corrected real" image (sign corrected magnitude effectively
the sort of output from PSIR) - this would be output for example by the commercial PSIR sequence
(and not would also be reflected in the DICOM tag 0x2005,0x1011)

Alternatively - I see that this is from an MP2RAGE sequence, this is not available from Philips
as the moment so is probably from a custom research software developed by a research group and
so, given that we provide access to virtually all the acquisition code and now recon pipeline modification,
it may be that the group has used this type to disambiguate the various outputs from the MP2RAGE sequence.

As to your other comments

1. This is in the DICOM as well but as a private tag.
2. no comment
3. we don't have a PAR to NIFTI converter but the scanner does now offer NIFTI output as a commercial option.

Some additional comments - the PAR-REC format was built for simpler times and its always been a tension between simplicity and comprehensiveness of the format. We are not actively changing PAR-REC for the future (and the files are versioned - in the PAR file, we have been at 4.2 for quite a long time now so you can check for support versions) and have introduced the XML-REC version in the commerical software which is more extensible for the long term. So while not actively deprecated, PAR-REC is getting a bit long in the tooth.

So PAR-REC (and NIFTI) we created to mainly address the problems of classic DICOM and put all
the images into a single file format, a problem now largely elimated due to Enhanced DICOM
performing this

For your addition comments on the NIFTI output from the scanner one of the problems is the lack of a documented "standard" for NIFTI - at the moment (and please correct me if im wrong) the only document is here ... https://nifti.nimh.nih.gov/nifti-1/ which we implemented from, and even then we ended up having two versions of the export for NIFTI and NIFTI-FSL and we only recommend using it for single typed image datasets for Diffusion and fMRI. Of course the use cases have extended to include ASL, anatomicals and B0 maps where the output formats are more complex and interleaved.

So if there were a published NIFTI standard to work to that would be very helpful for us as at seems that the moment the format and the tools are developing ad hoc but hand in hand.

Matthew

I

[neurolabusc]

Matthew-

Do you know the mapping of your enumerated list {"M","R","I","P","CR"....} to numbers used in the PAR/REC format (e.g. is it simply {0,1,2,3...}.

Thanks for your comments. I am not criticizing PAR/REC, it is an internal format and generally pretty clear. Though the format has not changed that much over the years, the implementation has changed, and features are being used that were not used before. When I developed my algorithm, all images in the PAR files I saw were saved in sequential (XYZT or TXYZ). This no longer seems to be the case (presumably data from parallel reconstructors is being added in the order it arrives). Likewise, I had assumed the top portion of the header provided a full guide for the variations. These are limitations of my implementation. They were justified at the time because they matched the data I had. However, it does mean my algorithm is a kludge. Thats why I would be happy for someone else to maintain this compatibility.

With regards to NIfTI, I am surprised that Philips makes a distinction between FSL and non-FSL NIfTI. I suspect it would be pretty easy to make a unified version. I wonder if a lot of these are archaic, as FSLview is now deprecated and replaced by the terrific FSLeyes that supports the NIfTI transforms as well as SPM. The FSL team does describe some of the quirks with their orientation expectations, in particular with DTI data (also described here). I think FSL is limited due to its pre-NIfTI analyze heritage. However, an image that works with FSL should work equally well with any other tools.

The main issue I have noted with the NIfTI header is that ITK-based tools give precedence to the QForm while other tools give precedence to the SForm. The original intention is that the QForm would tell you the image orientation in scanner space, while the SForm could be transforms to standard MNI space. The problem is that two images that appear aligned in SPM (which uses the SForm) may be misaligned with an ITK-based registration tool that is using the QForm. For this reason, I always set them to the same value. Certainly, this is the appropriate solution for any conversion from native scanner data to NIfTI space (as the standard space transform has not yet been computed).

I find the official NIfTI C header concise but clear. Perhaps you can describe what you find ambiguous about the format. From my perspective, NIfTI files are pretty hard to generate, as they make a lot of explicit demands (space is first three dimensions, time fourth, etc) but it is easy to write NIfTI image readers (since so many properties are enforced). Also, the simplicity makes the output of fslhd very consistent and quick to read as a human once you are familiar with it. On the other hand, NRRD files are very easy to generate. The NRRD text header is directly human readable (though has the traditionally ASCII issues supporting floating point). However, the flexibility makes it a bit harder to parse and makes a robust image viewer (that sorts out spatial orientation, sorts non-spatial dimensions) a bit harder. From 30,000 feet these formats are more similar than different (and much simpler than DICOM).