Hey Josh,
Thanks for bringing this to our attention. This newline, which was always ignored by our surface reading utils, was inadvertently removed after a large refactor of the codebase (moving to c++). This is an innocuous change except for the fact that it, of course, breaks external surface readers like nibabel. I just fixed this in the development version so that the extra newline is once again included in surface files. If you're having trouble reading a surface in nibabel, with the fixed version, you could just do...
mris_convert lh.surface lh.surface
...to save it correctly. The centos7 dev release has been updated with this fix, but you will have to wait until tomorrow for the centos6 release to rebuild.
Best, Andrew
________________________________________ From: freesurfer-bounces@nmr.mgh.harvard.edu freesurfer-bounces@nmr.mgh.harvard.edu on behalf of Joshua Jacobs joshuajacobs@flywheel.io Sent: Thursday, January 2, 2020 2:06 PM To: freesurfer@nmr.mgh.harvard.edu Subject: [Freesurfer] Surface file format differences
External Email - Use Caution
Hello,
When working with the nightly development version of FreeSurfer recon-all (freesurfer-linux-centos6_x86_64-dev.tar.gz 23-Dec-2019 06:01)
The surface file format differed by one character (\n) from previous versions. What makes me suspicious of this change is the difference between output and the fsaverage subject. See head -n 3 surf/rh.white for each below.
recon-all output: ���created by root on Tue Dec 31 23:05:44 2019 ���YcR@��]�zk=�}���m�K�4�F���h��{yM�����Ò���0@�(��ě��̫�VY�vտ�1G�s��@t�4�*��>���C80�d?f���5��˿O+@�H&�fˍ����ο�\i�.3��I� ^���dn���ٿp�7_��:�x����)��!�o���
fsaverage: ���created by greve on Thu Jul 19 12:52:07 2018
�A�3^�f�Bp�nA�
This is the case for all sample data in the FS/subjects/ directory save for "bert". The data of which had been produced on 2019-12.21.
Although I have not tried freeview on these files, it fails to open in the python library nibabel.freesurfer.io.load_geometry.
Is this change intended?
Thank You.
Josh J.