[RTM] Gifti surfaces #398

effigies · 2017-03-20T15:42:31Z

Generate midthickness surfaces
Convert to Gifti
Output to fmriprep/sub-<subject_label>/anat/sub-<subject_label>_T1w_<surfname>.[LR].surf.gii
Check alignment
- Update xform matrix in Gifti if needed.

Closes #394.

effigies · 2017-03-20T17:45:48Z

Alignment is currently off.

effigies · 2017-03-20T18:11:45Z

Unchecking midthickness... The technique I have for creating it doesn't preserve the xform matrix, which suggests nibabel's read_geometry is incomplete. Going to follow this strategy which means a new nipype interface for mris_expand.

effigies · 2017-03-21T17:14:51Z

Still having issues with Connectome workbench compatibility, but Freeview alignment looks okay. (Red: smoothwm; Green: midthickness, Blue: pial).

The volume here is the fmriprep/anat/sub-01_T1w_preproc.nii.gz, not freesurfer/sub-01/mri/T1.mgz.

Weirdly, the xform doesn't seem to be preserved by mris_expand, either, but this could be me fiddling around in the working directory and confusing myself. Rebased against master and going to try in a clean(ish...) working directory.

chrisgorgo · 2017-03-21T17:40:35Z

Is the picture above freeview or connectome workbench? Did you try loading freesurfer/sub-01/mri/T1.mgz in connectome workbench?

…

On Tue, Mar 21, 2017 at 10:14 AM, Chris Markiewicz ***@***.*** > wrote: Still having issues with Connectome workbench compatibility, but Freeview alignment looks okay. (Red: smoothwm; Green: midthickness, Blue: pial). [image: freeview] <https://cloud.githubusercontent.com/assets/83442/24159476/8747e182-0e35-11e7-820b-a56544a4f62d.png> The volume here is the fmriprep/anat/sub-01_T1w_preproc.nii.gz, not freesurfer/sub-01/mri/T1.mgz. Weirdly, the xform doesn't seem to be preserved by mris_expand, either, but this could be me fiddling around in the working directory and confusing myself. Rebased against master and going to try in a clean(ish...) working directory. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#398 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkp_e7CIihTycnXsBnbaNa8elWvHLaks5roAWLgaJpZM4MinD4> .

effigies · 2017-03-21T17:53:19Z

Latest is freeview. Earlier is wb_view.

This is wb_view with the pial surface outline over the FreeSurfer conformed T1 (converted to .nii.gz, because wb_view doesn't like .mgz).

So basically the same situation. However, there's something weirder going on with wb_view. This is their "all" view, instead of the "volume" view:

The surface is correctly oriented, but the horizontal/coronal/axial slices are messed up.

chrisgorgo · 2017-03-21T18:10:37Z

Indeed weird - as if it was shifted by a few voxels. In HCP pipelines they seem to be applying an affine to this surface: https://github.com/Washington-University/Pipelines/blob/master/PostFreeSurfer/scripts/FreeSurfer2CaretConvertAndRegisterNonlinear.sh#L230

chrisgorgo · 2017-03-21T18:11:36Z

Which is defined here:
https://github.com/Washington-University/Pipelines/blob/master/PostFreeSurfer/scripts/FreeSurfer2CaretConvertAndRegisterNonlinear.sh#L147

chrisgorgo · 2017-03-21T18:11:56Z

If this does not help it might be worth asking on the hcp-users mailing list.

effigies · 2017-03-21T18:44:36Z

Thanks. It looks like this c_ras is what I want, which I'm pretty sure I've seen in the surface file metadata. (And in the GIFTIs, so you'd think that wb_view should be able to handle that.)

chrisgorgo · 2017-03-21T19:08:11Z

I hope the resulting giftis will still align in freeview!

effigies · 2017-03-21T19:13:04Z

Yeah, that's my worry. If it's just a shift to the offset column, I may be able to zero out c_ras to prevent FreeSurfer double-applying.

effigies · 2017-04-04T10:46:19Z

Almost there...

Only remaining issue is that wb_view won't load the midthickness files we're creating. I'm pretty sure this is because midthickness isn't being created with an xform matrix, which I believe is because mris_expand doesn't have enough local files to pull in. This'll require either patching in from the other GIFTIs, or updating the nipype interface.

effigies · 2017-04-04T13:22:52Z

It was not mris_expand, but mris_convert. In order to correctly generate these gifti files, we need the midthickness file to be in the FreeSurfer tree, or at least a copy of it. I'm inclined to DataSink the FreeSurfer ?h.midthickness into the derivatives/freesurfer/sub-{label}/surf/ directory. This also makes sense to me because the midthickness surface should be available whether a user is using FreeSurfer derivatives directly or our derivative GIFTI file.

effigies · 2017-04-04T16:56:06Z

Okay. Finally tracked down the actual issue, which is that wb_view doesn't know what to do with a file that's missing some metadata, and FreeSurfer doesn't know to set the AnatomicalStructureSecondary = MidThickness and GeometricType = Anatomical metadata for midthickness surfaces.

Still, we now have

Talairach transform metadata
AnatomicalStructureSecondary/GeometricType metadata
Correct viewing in wb_view, freeview.

effigies · 2017-04-04T16:58:13Z

This needs docs, and I want to update the node names to make the graph more informative. But this is working.

chrisgorgo · 2017-04-04T16:59:05Z

Awesome - excellent work!

…

On Tue, Apr 4, 2017 at 9:58 AM, Chris Markiewicz ***@***.***> wrote: This needs docs, and I want to update the node names to make the graph more informative. But this is working. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#398 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOkp-43VceXE9-1nioDfOg5oFDDfKjdks5rsnalgaJpZM4MinD4> .

effigies · 2017-04-04T19:09:16Z

That whole right cluster is FreeSurfer stuff. Might make sense to split FreeSurfer anatomical processing out into a sub-workflow (in another PR) at this point?

chrisgorgo · 2017-04-04T21:10:15Z

yes - it would help with the code readability as well

effigies · 2017-04-04T23:01:57Z

Good to merge this and then refactor into its own workflow?

chrisgorgo · 2017-04-05T16:00:22Z

Cool - could you link the issue your reported with HCP folks for reference?

We should merge this as soon as nipy/nipype#1938 is resolved.

effigies · 2017-04-05T16:20:36Z

It was a bug report. Here's the text:

 ________________________________________ From: Christopher Markiewicz Sent: Wednesday, April 5, 2017 10:52 AM To: workbench_bugs@brainvis.wustl.edu Subject: BUG: wb_view not aligning slices Hi all, I'm trying to use `wb_view` to verify surface and volume alignment, and ran across a weird issue with displaying volumes, where the coordinates don't seem to be consistent across the three views. Screenshot (and context): https://github.com/poldracklab/fmriprep/pull/398#issuecomment-291880528 The sagittal and coronal slices are only slightly off, but the horizontal slices show a view significantly superior to that of the other two slices. I have this issue whether I'm working with the raw T1 or a conformed version. The data is from sub-01 in the OpenFMRI dataset ds000114 (https://openfmri.org/dataset/ds000114/), if you need to reproduce. Any help would be greatly appreciated. Full report follows signature. -- Chris Markiewicz Center for Reproducible Neuroscience Stanford University ----- (1) SUMMARY_OF_PROBLEM Misaligned slice views: Given a slice plane, selecting a coordinate does not set the correct view in the other two slices. This makes surface alignment verification impossible. (2) HOW TO REPRODUCE PROBLEM Load volume into wb_view, and view in "(3) Volume" tab. (3) WHAT HAPPENS Slices are misaligned. (4) WHAT SHOULD HAPPEN Slices should be aligned. (5) NAME OF UPLOADED DATA ZIP FILE (Press "Upload Data" button to go to the upload website) sub-01_ses-test_T1w.nii.gz (6) SCREEN CAPTURES - After this information is copied into your email client, image captures (File Menu->Capture Image) that help describe the bug may be copied into the email message. https://cloud.githubusercontent.com/assets/83442/24710442/1b56e196-19eb-11e7-9857-1406f2bd2cd8.png ------------------------------------------------------------------ PLEASE DO NOT CHANGE TEXT BELOW THIS LINE. It is used to help us understand the context of your reported bug. Connectome Workbench Type: Graphical User Interface Application Version: 1.2.3 Qt Compiled Version: 4.8.7 Qt Runtime Version: 4.8.7 Commit: unknown Commit Date: unknown Compiled with OpenMP: YES Compiler: x86_64-linux-gnu-g++ (/usr/bin) Compiler Version: 5.3.1 Compiled Debug: NO Operating System: Linux OpenGL Context: Accum: false Accum size: -1 Alpha: true Alpha size: 8 Depth: true Depth size: 24 Direct Rendering: true Red size: 8 Green size: 8 Blue size: 8 Double Buffer: true RGBA: true Samples: false Samples size: -1 Stencil: true Stencil size: 8 Swap Interval: 0 Stereo: false Major Version: 1 Minor Version: 0 OpenGL Header File Versions Supported: 1.1 1.2 1.3 1.4 1.5 2.0 2.1 3.0 3.1 3.2 3.3 4.0 4.1 4.2 4.3 4.4 4.4 4.5 OpenGL Runtime Version: 3.0 Mesa 12.0.6 Major Runtime Version: 3 Minor Runtime Version: 0 OpenGL Vendor: Intel Open Source Technology Center OpenGL Renderer: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) Font Renderer: FTGL Text Renderer GL_ALIASED_LINE_WIDTH_RANGE value is 1, 7.375 GL_SMOOTH_LINE_WIDTH_RANGE value is 1, 7.375 GL_SMOOTH_LINE_WIDTH_GRANULARITY value is 0.125 GL_LINE_WIDTH_RANGE value is 1, 7.375 GL_LINE_WIDTH_GRANULARITY value is 0.125 Maximum number of clipping planes is 8 Maximum Modelview Matrix Stack Depth 32 Maximum Name Matrix Stack Depth 64 Maximum Projection Matrix Stack Depth 32 Buffer bits red/green/blue/apha: (8, 8, 8, 8) Best Drawing Mode: Display Lists Display Lists Supported: true Immediate Mode Supported: true Vertex Buffers Supported: true Note that State of OpenGL may be different when drawing objects. Fixed Pipeline State: GL_BLEND=false GL_CLIP_PLANE0=false GL_CLIP_PLANE1=false GL_CLIP_PLANE2=false GL_CLIP_PLANE3=false GL_CLIP_PLANE4=false GL_CLIP_PLANE5=false GL_COLOR_MATERIAL=false GL_CULL_FACE=true GL_DEPTH_TEST=true GL_LIGHT_MODEL_LOCAL_VIEWER=false GL_LIGHT_MODEL_TWO_SIDE=false GL_LIGHTING=false GL_LIGHT0=true GL_LIGHT1=false GL_LIGHT2=false GL_LIGHT3=false GL_LIGHT4=false GL_LIGHT5=false GL_LIGHT0, GL_DIFFUSE=(0.9,0.9,0.9,1) GL_LIGHT0, GL_POSITION=(0,0,1,0) GL_LIGHT1, GL_DIFFUSE=(0.9,0.9,0.9,1) GL_LIGHT1, GL_POSITION=(0,0,1,0) GL_LIGHT_MODEL_AMBIENT=(0.8,0.8,0.8,1) GL_LINE_SMOOTH=false GL_NORMALIZE=true GL_POLYGON_OFFSET_FILL=false GL_POLYGON_SMOOTH=false Front Face GL_CCW Cull Face INVALID At least 1 display lists are allocated in first OpenGL context. At least 0 vertex buffers are allocated

chrisgorgo · 2017-04-05T18:34:01Z

Another weird observation - lh.pial is a symlink and rh.pial is a copy (the ls was performed while the nodes were still running)

root@fb7003e2bbbd:~/src/fmriprep# ls -al /scratch/workflow_enumerator/01/t1w_preprocessing/MidThickness/mapflow/_MidThickness0 total 30 drwxr-xr-x 2 root root 4096 Apr 5 18:24 . drwxr-xr-x 2 root root 0 Apr 5 18:24 .. -rwxr-xr-x 1 root root 265 Apr 5 18:24 _inputs.pklz -rwxr-xr-x 1 root root 1455 Apr 5 18:24 _node.pklz drwxr-xr-x 2 root root 0 Apr 5 18:24 _report -rwxr-xr-x 1 root root 353 Apr 5 18:24 command.txt -rwxr-xr-x 1 root root 171 Apr 5 18:24 error.log lrwxrwxrwx 1 root root 36 Apr 5 18:24 lh.pial -> //out/freesurfer/sub-01/surf/lh.pial lrwxrwxrwx 1 root root 40 Apr 5 18:24 lh.smoothwm -> //out/freesurfer/sub-01/surf/lh.smoothwm lrwxrwxrwx 1 root root 38 Apr 5 18:24 lh.sphere -> //out/freesurfer/sub-01/surf/lh.sphere lrwxrwxrwx 1 root root 41 Apr 5 18:24 lh.thickness -> //out/freesurfer/sub-01/surf/lh.thickness -rwxr-xr-x 1 root root 1216 Apr 5 18:24 result__MidThickness0.pklz root@fb7003e2bbbd:~/src/fmriprep# ls -al /scratch/workflow_enumerator/01/t1w_preprocessing/MidThickness/mapflow/_MidThickness1 total 3598 drwxr-xr-x 2 root root 4096 Apr 5 18:24 . drwxr-xr-x 2 root root 0 Apr 5 18:24 .. -rwxr-xr-x 1 root root 436 Apr 5 18:24 _0x615c0a162a16f2030f00de99caa2029c_unfinished.json -rwxr-xr-x 1 root root 266 Apr 5 18:24 _inputs.pklz -rwxr-xr-x 1 root root 1455 Apr 5 18:24 _node.pklz drwxr-xr-x 2 root root 0 Apr 5 18:24 _report -rwxr-xr-x 1 root root 353 Apr 5 18:24 command.txt -rwxr-xr-x 1 root root 3659035 Apr 5 18:24 rh.pial lrwxrwxrwx 1 root root 40 Apr 5 18:24 rh.smoothwm -> //out/freesurfer/sub-01/surf/rh.smoothwm lrwxrwxrwx 1 root root 38 Apr 5 18:24 rh.sphere -> //out/freesurfer/sub-01/surf/rh.sphere lrwxrwxrwx 1 root root 41 Apr 5 18:24 rh.thickness -> //out/freesurfer/sub-01/surf/rh.thickness

effigies · 2017-04-05T18:42:25Z

I'm going to bet what happened there was that attempting to symlink rh.pial failed, so filemanip.copyfile fell back to copying. You have a stochastically symlinkable filesystem, it looks like.

effigies · 2017-04-05T20:06:25Z

Email thread:

From: Harwell, John jharwell@wustl.edu
Sent: Wednesday, April 5, 2017 3:52 PM
To: Christopher Markiewicz
Cc: Harwell, John; Coalson, Timothy; Elam, Jennifer
Subject: Re: wb_view not aligning slices

From viewing the output of "wb_command -nifti-information sub-01_ses-test_T1w.nii.gz -print-header”, the volume appears to be in “scanner based anatomical coordinates”. This is indicated by the storm_code and form_code both set to 1 (See https://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h; search for NIFTI_XFORM_SCANNER_ANAT).

Since the volume is obliquely oriented and the origin is not at the anterior commissure, that is what causes its appearance in wb_view. For the volume to display correctly in wb_view, the volume needs to be in an orthogonal orientation with the origin (coordinate 0, 0, 0) at the anterior commissure. Essentially, some variation of Talairach Space.

In the Toolbar’s “Slice Indices/Coords” section is a combo box (pop-up menu) that is probably set to Orthogonal and if you click it, it should pop up a menu from which you can select “Oblique”. When obliquely viewed, the crosshairs should be at the same location in each slice.

Output of wb_command -nifti-information sub-01_ses-test_T1w.nii.gz -print-header

native endian: true sizeof_hdr: 348 magic: n+1 datatype: 16 bitpix: 32 dim[0]: 3 dim[1]: 256 dim[2]: 156 dim[3]: 256 pixdim[0]: 1 pixdim[1]: 1 pixdim[2]: 1.29938 pixdim[3]: 1 vox_offset: 352 scl_slope: 1 scl_inter: 0 sform_code: 1 srow_x: 0.999132 -0.0516292 0.0125127 -125.264 srow_y: 0.0407722 1.29202 -0.0981179 -73.133 srow_z: -0.00854507 0.128044 0.995096 -177.554 qform_code: 1 quatern_b: 0.0492356 quatern_c: 0.00527198 quatern_d: 0.0201553 qoffset_x: -125.264 qoffset_y: -73.133 qoffset_z: -177.554

Output of wb_command -file-information sub-01_ses-test_T1w.nii.gz

Type: Volume Structure: Invalid Data Size: 40.89 Megabytes Maps to Surface: false Maps to Volume: true Maps with LabelTable: false Maps with Palette: true All Map Palettes Equal: true Map Interval Units: NIFTI_UNITS_UNKNOWN Number of Maps: 1 Orthogonal: false NIFTI Version: 1 NIFTI Data Type: NIFTI_TYPE_FLOAT32 Dimensions: 256, 156, 256 IJK = (0,0,0): XYZ = (-125.264, -73.133, -177.554) X-minimum: -133.798 X-maximum: 133.237 Y-minimum: -98.869 Y-maximum: 138.243 Z-minimum: -180.299 Z-maximum: 96.608 Orientation[0]: Left to Right Orientation[1]: Posterior to Anterior Orientation[2]: Inferior to Superior Spacing: 0.960014, 1.23467, 1.11459

On Apr 5, 2017, at 12:52 PM, Christopher Markiewicz <markiewicz@stanford.edu mailto:markiewicz@stanford.edu> wrote:

Thanks for the reply.

I've uploaded the file: sub-01_ses-test_T1w.nii.gz

From: Harwell, John <jharwell@wustl.edu mailto:jharwell@wustl.edu>
Sent: Wednesday, April 5, 2017 1:23:49 PM
To: Christopher Markiewicz
Cc: Coalson, Timothy; Elam, Jennifer
Subject: Re: wb_view not aligning slices

Hi Chris,

It looks like the volume has an origin that is not at the anterior commissure and/or the volume is not in an orthogonal orientation. The axial view clearly shows rotation and there is also probably some rotation in coronal view. You can run “wb_command -file-information” on the volume file and it may provide some helpful information such as indication of the volume’s oblique/orthogonal status. Alternatively, if there is some easy way for me to get the volume file (I have no understanding of openfrmi.orghttp://openfrmi.org http://openfrmi.org), I could look further into the problem. You can upload the volume file at http://pulvinar.wustl.edu/cgi-bin/upload.cgi and if you do, send me an email after the file has uploaded.

John H

effigies · 2017-04-05T20:11:56Z

So if we view in oblique mode, surfaces line up:

effigies · 2017-04-09T01:40:51Z

Updated docs and nipype dependency for nipy/nipype#1941.

Ready to merge when build test finishes.

effigies force-pushed the gifti_surfaces branch from ea1ede8 to 2c52ee0 Compare March 20, 2017 16:32

effigies force-pushed the gifti_surfaces branch 2 times, most recently from 8f6f08e to e06b4da Compare March 21, 2017 17:07

effigies force-pushed the gifti_surfaces branch 4 times, most recently from b724cf6 to 3d1f97d Compare March 27, 2017 12:42

effigies force-pushed the gifti_surfaces branch 2 times, most recently from ac22d3e to 0296dc9 Compare April 4, 2017 10:44

effigies changed the title ~~[WIP] Gifti surfaces~~ [RTM] Gifti surfaces Apr 4, 2017

effigies force-pushed the gifti_surfaces branch from 69a2777 to ee4ec98 Compare April 4, 2017 19:06

effigies mentioned this pull request Apr 5, 2017

ENH: Disable symlinks on CIFS filesystems nipy/nipype#1941

Merged

chrisgorgo mentioned this pull request Apr 5, 2017

Normalize set the origin point of the output T1w volume to AC #433

Closed

effigies force-pushed the gifti_surfaces branch from ee4ec98 to 392507f Compare April 7, 2017 20:48

effigies added 9 commits April 8, 2017 08:19

Generate midthickness, Gifti surfs

bcf6321

STY: PEP8, more descriptive node names

87ad904

Use FreeSurferSource and MRIsExpand to get surfaces

3230fcc

Specify midthickness at interface instantiation

fab341a

Join and rename surfaces to match GIFTI convention

ec51909

Use ReconAll outputs to source Gifti files

5f48e72

Save surfaces to derivatives

f53dc2d

Recenter GIFTI surfaces based on C_RAS translation

38a31b2

Save midthickness in FS dir, update GIFTI metadata

fb8517c

effigies force-pushed the gifti_surfaces branch 2 times, most recently from 6762c8f to 710fe04 Compare April 9, 2017 01:37

effigies added 3 commits April 8, 2017 21:38

DOC: Document surface derivatives

ecb626f

STY: Update node names

79f21df

Update Nipype pin

829ad39

effigies force-pushed the gifti_surfaces branch from 710fe04 to 829ad39 Compare April 9, 2017 01:39

chrisgorgo merged commit 57572ed into nipreps:master Apr 9, 2017

effigies deleted the gifti_surfaces branch April 10, 2017 13:04

effigies mentioned this pull request Apr 10, 2017

[RTM] RF: Split out surface recon workflow #437

Merged

effigies mentioned this pull request Apr 24, 2017

Skip mris_expand on pre-existing graymid/midthickness files #477

Closed

effigies mentioned this pull request Oct 4, 2023

Susceptibility distortion correction introduces distortion #3013

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[RTM] Gifti surfaces #398

[RTM] Gifti surfaces #398

Uh oh!

effigies commented Mar 20, 2017 •

edited

Loading

effigies commented Mar 20, 2017

effigies commented Mar 20, 2017

effigies commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017 via email

effigies commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017

effigies commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017

effigies commented Mar 21, 2017

effigies commented Apr 4, 2017

effigies commented Apr 4, 2017

effigies commented Apr 4, 2017

effigies commented Apr 4, 2017

chrisgorgo commented Apr 4, 2017 via email

effigies commented Apr 4, 2017

chrisgorgo commented Apr 4, 2017

effigies commented Apr 4, 2017

chrisgorgo commented Apr 5, 2017

effigies commented Apr 5, 2017

chrisgorgo commented Apr 5, 2017

effigies commented Apr 5, 2017

effigies commented Apr 5, 2017

effigies commented Apr 5, 2017

effigies commented Apr 9, 2017

Labels

2 participants

[RTM] Gifti surfaces #398

[RTM] Gifti surfaces #398

Uh oh!

Conversation

effigies commented Mar 20, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

effigies commented Mar 20, 2017

effigies commented Mar 20, 2017

effigies commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017 via email

effigies commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017

effigies commented Mar 21, 2017

chrisgorgo commented Mar 21, 2017

effigies commented Mar 21, 2017

effigies commented Apr 4, 2017

effigies commented Apr 4, 2017

effigies commented Apr 4, 2017

effigies commented Apr 4, 2017

chrisgorgo commented Apr 4, 2017 via email

effigies commented Apr 4, 2017

chrisgorgo commented Apr 4, 2017

effigies commented Apr 4, 2017

chrisgorgo commented Apr 5, 2017

effigies commented Apr 5, 2017

chrisgorgo commented Apr 5, 2017

effigies commented Apr 5, 2017

effigies commented Apr 5, 2017

effigies commented Apr 5, 2017

effigies commented Apr 9, 2017

Labels

2 participants

effigies commented Mar 20, 2017 •

edited

Loading