Hi Matthew,
Thanks for getting back at this. We only process data for our users, so I don't
have permission to share a sample with you. But I'll ask around to see if I can
get a scan for you.
To be honest, we aren't quite sure if the problem is with nibabel (v1.3.0). I
tried to reproduce the problem with one of the scan that was causing this
problem, but the conversion worked fine for me (same data, same script,
different platform). Although recently we had the same issue cropping up again
for another user where only part of the data was affected by this problem. All
we know is that the description field of the NIFTI header starts at the right
offset, the magic number bytes are off by +one byte, and the brain looks
skewed; hence the assumption of an extra byte in one of the transform fields.
Alternatively, we were wondering what happens if the content of the description
field exceeded 80 characters
descr = "%s;%s;%s;%s" % (
pr_hdr.general_info['exam_name'],
pr_hdr.general_info['patient_name'],
pr_hdr.general_info['exam_date'].replace(' ',''),
pr_hdr.general_info['protocol_name'])
nhdr.structarr['descrip'] = descr[:80]
The python code neatly truncates the description to 80 characters. Could it be
possible that an extra '\0' null byte gets written to terminate the string,
causing the description field to be 81 bytes long?
Cheers,
Jalmar
> On 10 Jun 2015, at 18:42, Matthew Brett <matthew.br...@gmail.com> wrote:
>
> Hi,
>
>> We had the same problem with importing scans into Freesurfer that had been
>> converted from PAR/REC to NIFTI using nipy. The problem only affected a
>> subset of the data. When visualising the data with Fiji the brain appeared
>> highly skewed. Upon closer inspection of the header data of the NIFTI file we
>> discovered that there was an extra byte somewhere between the description
>> fields and the magic number sequence, causing the magic number to be
>> misinterpreted by Freesurfer. The extra byte was somewhere in the
>> transformation matrix that is located between the description field and the
>> magic number, but it's impossible to fix unless you know what the content of
>> the transformation matrix is supposed to be. However, when using dcm2nii,
>> part of mricron (from what I understand a newer version of mricro), to
>> convert our PAR/REC files to NIFTI the problem disappeared.
>
> I'm the maintainer of nibabel so I guess I'm responsible for this
> bug... Can someone point me to a PAR / REC file that causes this
> problem? Private off-list is fine, but an image I can share for
> automated testing would be even better...
>
> Cheers,
>
> Matthew
> _______________________________________________
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> The information in this e-mail is intended only for the person to whom it is
> addressed. If you believe this e-mail was sent to you in error and the e-mail
> contains patient information, please contact the Partners Compliance HelpLine
> at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
