parrec load, different keywords

[steso]

Hi
I try to read par/rec files, however some of the keywords in my par header differ. (e.g. Repetition time [msec] instead of [ms]). I tried to modify my parrec.py accordingly, however if I change the keywords in parrec.py _hdr_key_dict, nothing changes (still the old values instead of the corrected). Obviously I don't understand the code (yet), maybe somebody could point me into the right direction? And what woud be the best way account for these slight changes in the header?
Thanks in advance

[matthew-brett]

Can you post at least an example .PAR file somewhere we can have a look? You're right, it's not particularly easy to deal with small variations in the format, we'll have to put in some explicit regular expressions or similar.

[steso]

Ok here is one of my par-files:
https://www.dropbox.com/s/q5ilcqclvw36b75/invivo.par?dl=0
The differences are in the following properties:

• Series_data_type
• Patient Position
• Repetition time [msec]
• Diffusion echo time [msec]

The error occurs in parrec.py in parse_PAR_header(fObj) in the following line:

# get props for this hdr field
props = _hdr_key_dict[key]

However, what I still don't understand, if I modify the _hdr_key_dict in that particular file (parrec.py) and re-run my code, the key values in _hdr_key_dict are still the old ones. Is the _hdr_key_dict stored somewhere else and loaded?
I just wanted to change the mentioned _hdr_key values as a quick fix instead of changing all of the par-files.

[grlee77]

I just took a quick look at the .PAR file. I see that it is still labelled as a V4.2 PAR which we nominally support. Disappointing that apparently being V4.2 doesn't guarantee identical field names, etc. Do you know which Philips software release the scanner that acquired this is running? I haven't looked at .PAR files from the fairly recent V5.3 release, yet, but perhaps that is when the change occurred?

Fortunately there are no entirely new header fields or data columns, so I don't think it should be too hard to fix. will take a quick look now.

[matthew-brett]

Looking at our example files, most of them seem to be V4.2 - so this must be a variation in the V4.2 format - I agree, it would be good to understand where this variation comes from...

[steso]

They should be from a release 3-ish (I guess 3.2.1) system. I can check and compare the 5.3 release par-files next week if it helps, still not sure why the simple renaiming worksround doesn't work...

[matthew-brett]

Workaround will surely work, but the general question is - what level of variability can we expect from these types of files.

I don't understand Philips stuff at all - is it surprising that a 3.2.1 system generates 4.2 format files?

[grlee77]

The PAR versioning is entirely separate from the system software. The system software versions change much more often as new features, sequences types, etc. are added. You have to go back to a pretty old system software (prior to 3.2 or so) to get a .PAR file that is not V4.2. What appears to be the case is that ocassionally the PAR format has been tweaked slightly, without a corresponding change in the version number label.

I think just adding duplicate entries to _hdr_key_dict such as the following should work:

    # The following are duplicates of the above fields, but with slightly
    # different abbreviation, spelling, or capatilization.  Both variants have
    # been observed in the wild in files that are nomincally V4.2 PAR files.
    'Series_data_type': ('series_type',),
    'Patient Position': ('patient_position',),
    'Repetition time [msec]': ('repetition_time', float, None),
    'Diffusion echo time [msec]': ('diffusion_echo_time', float),

Thus there would be two different strings that would match to series_type, etc. There should never be a case where both variants are in the same file. not the most elegant, but should be a quick workaround.

@steso: not sure why something like this didn't work when you tried it. Are you sure the parrec.py you are importing is really the same one you modified and not perhaps a different copy or something?

[matthew-brett]

@steso - can we put that example .PAR file into the nibabel distribution as a test? I mean, are you OK to release it under a PDDL license as in https://github.com/nipy/nibabel/blob/master/COPYING#L195 ?

[grlee77]

verified that the above change works with the following basic test

from nibabel.openers import ImageOpener
from nibabel.parrec import parse_PAR_header

parfile = 'invivo.par'
with ImageOpener(parfile, 'rt') as _fobj:
    HDR_INFO, HDR_DEFS = parse_PAR_header(_fobj)

All of the fields corresponding to the alternative spelling end up in HDR_INFO as expected. should a make a PR with this approach? I don't think it is probably worth tyring to implement a more general parsing, unless we had some means of knowing what all the potential variants were.

[matthew-brett]

Yeah - that's fine, please do. It would be ideal to have the example file as the test file, but if not, just edit one of the existing files with the changes, commit that?

[grlee77]

Another difference I just noticed is that the value listed for the Patient Position field is HFS, but in our other V4.2 .PAR files it would be spelled out as Head First Supine. As far as I can tell that shouldn't cause a problem during conversion as I don't think it is used? I think it is only the angulation fields and slice orientation codes that get used in determining the orientation info for the NIFTI.

[matthew-brett]

I don't remember that field being used anywhere - worth a quick grep to check though.

[grlee77]

doesn't appear to be used. opened a PR now at #507

[steso]

Thanks for all of your efforts. It shouldn't be a problem to include my par-file in the repository, however in order to be save it might be better to just rename the tags of the existing par-file. The problem I had with renaming the dictionary keys directly was that I didn't restart the python console (instead of only reloading nibabel).
Additionally, I uploaded a par-file from a 5.3 system:
https://www.dropbox.com/s/9ddy70ebpgsoxje/invivo53.par?dl=0