gallantlab / pycortex

Pycortex is a python-based toolkit for surface visualization of fMRI data
https://gallantlab.github.io/pycortex
BSD 2-Clause "Simplified" License
597 stars 139 forks source link

equivolume to-do's #262

Open alexhuth opened 6 years ago

alexhuth commented 6 years ago

(This is copied from the equivolume pull request that has been merged. I'm moving this here to keep track of these issues & discuss if there's interest.)

Here's an example viewer with equivolume stratification included, click/unclick the "equivolume" button to see the effect: http://alexghuth.com/brainviewers/S1-equivolume/

To recap the point of equivolume stratification: This changes the behavior of the 'depth' slider, so that for a selected depth (e.g. depth=0.5), the resulting surface is not halfway between the pial and white matter surfaces, but is instead a surface that has half of the cortical volume above it and half of the cortical volume below it. This obeys "Bok's principle", and much more accurately matches actual cortical layers than the current method.

In preliminary testing volume-based straficiation seems to have a modest effect on the mapping of high-resolution data, such as T1-weighted volumes, but I haven't tested lower resolution functional data. In particular, I found that the new method yields T1w maps that are less confounded by surface curvature than the old method, which suggests that it is indeed more accurate.

Currently equivolume-mode is disabled by default, and can be enabled in a webgl viewer by checking a box labeled 'equivolume'. In my opinion there is no reason to prefer the old distance-based cortical surfaces to the new volume-based surfaces, so I think the default should probably be that it is on, but that can be discussed.

The equation for determining the location of a cortical surface using volume-based sampling comes from this paper: http://www.sciencedirect.com/science/article/pii/S1053811913003480

More information about this technique can also be found here: http://brainvoyager.com/bv/doc/UsersGuide/HighResDataAnalysis/EquiVolumeDepthModelling.html

Things that I think should happen but don't want to do without further discussion:

kwagstyl commented 6 years ago

Hi Alex + pycortex,

A couple of minor additions:

The current equidistant method overweights lower layers in gyri, upper layers in sulci.

Also, having experimented further with this surface-based approach, it can be useful to smooth the pial and white surface areas used to calculate the equivolumetric surfaces. This mitigates that lack of ideal correspondence between pial and white surfaces. More smoothing causes the intra cortical surfaces to tend towards being approximately equidistant surfaces.

On 2018-03-27 15:36, Alex Huth wrote:

(This is copied from the equivolume pull request that has been merged. I'm moving this here to keep track of these issues & discuss if there's interest.)

Here's an example viewer with equivolume stratification included, click/unclick the "equivolume" button to see the effect: http://alexghuth.com/brainviewers/S1-equivolume/ [1]

To recap the point of equivolume stratification: This changes the behavior of the 'depth' slider, so that for a selected depth (e.g. depth=0.5), the resulting surface is not halfway between the pial and white matter surfaces, but is instead a surface that has half of the cortical volume above it and half of the cortical volume below it. This obeys "Bok's principle", and much more accurately matches actual cortical layers than the current method.

In preliminary testing volume-based straficiation seems to have a modest effect on the mapping of high-resolution data, such as T1-weighted volumes, but I haven't tested lower resolution functional data. In particular, I found that the new method yields T1w maps that are less confounded by surface curvature than the old method, which suggests that it is indeed more accurate.

Currently equivolume-mode is disabled by default, and can be enabled in a webgl viewer by checking a box labeled 'equivolume'. In my opinion there is no reason to prefer the old distance-based cortical surfaces to the new volume-based surfaces, so I think the default should probably be that it is on, but that can be discussed.

The equation for determining the location of a cortical surface using volume-based sampling comes from this paper: http://www.sciencedirect.com/science/article/pii/S1053811913003480 [2]

More information about this technique can also be found here: http://brainvoyager.com/bv/doc/UsersGuide/HighResDataAnalysis/EquiVolumeDepthModelling.html [3]

Things that I think should happen but don't want to do without further discussion:

  • The behavior of the depth parameter in quickflat should be changed to match webgl (and, what I have learned, is preferred by anatomists): depth=0 corresponds to the pial surface, and depth=1 corresponds to the white matter surface. (Interestingly, anatomists prefer this because the pial boundary is extremely clear while the gray/white boundary is somewhat open for interpretation.) This is a pretty minor change and shouldn't affect most people, afaik.
  • I think we should replace the current method for computing the fiducial surface, which is equidistant from the pial and wm surfaces, with a mid-cortical surface that has equal volume above and below. This is a much larger change, but I'm not sure how broad the effects would be. Please give me thoughts.
  • We should consider changing the behavior (or enabling as an alternative) of depth-averaged sampling (in quickflat and webgl) so that it uses volume-based instead of distance-based stratification. This would have the effect of equally weighting data from each cortical layer. The current method overweights deep layers in sulci (because they have larger volume there) and overweights shallow layers on gyri (same).
  • Based on conversations with @kwagstyl [4] I'm leaning more heavily toward the prospect of replacing the smoothwm surfaces that we take from freesurfer with the more standard white surfaces. One potential issue with volume-based stratification (and, to be fair, with the old method as well) is that it relies strongly on the correspondence that freesurfer establishes between vertices on the pial and white matter surfaces. That correspondence is approximate in any case, but seems much more likely to be accurate in the original white surface than in smoothwm.

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [5], or mute the thread [6].

*

Links:

[1] http://alexghuth.com/brainviewers/S1-equivolume/ [2] http://www.sciencedirect.com/science/article/pii/S1053811913003480 [3] http://brainvoyager.com/bv/doc/UsersGuide/HighResDataAnalysis/EquiVolumeDepthModelling.html [4] https://github.com/kwagstyl [5] https://github.com/gallantlab/pycortex/issues/262 [6] https://github.com/notifications/unsubscribe-auth/ATLTxqlKTJ4yV8f9Z2So5LYMPFwdmlKlks5tik52gaJpZM4S9C7q

marklescroart commented 6 years ago

If I am reading kwagstyl's post right, it sounds like s/he is leaning towards using the smoothed surfaces, yes? I'm in favor of this, because I'd be afraid that the un-smoothed surfaces would be overfit to an individual anatomical scan. I know that some (many?) of the surfaces we have in use are from an average of 2 or more anatomical scans, but even so - there are still voxels, and thus I would fear that the un-smoothed surfaces would conform too tightly to an artificial rectangular grid. I suspect that if you were to coregister a new anatomical scan to the one used for generation of the surface (whether that is an average or not), and project that data onto the surface, the smoothed surface would give better results. Thoughts, @alexhuth ?

Re: all else, this sounds like a smarter way to do things, and none of my pipelines (nor any that I am aware of in glab) would seem to be strongly affected by the proposed changes. So I'm for it.

kwagstyl commented 6 years ago

Hi Mark,

To be clear I was suggesting surface-based smoothing of the area values used when calculating the fractional depth, rather than smoothing the white mesh surfaces themselves. The argument against smoothing the white mesh are: 1) you are likely to shrink the white surface away from the cortex in gyral crowns more than elsewhere, introducing a systematic bias sampling data. ** 2) You are likely to disrupt whatever correspondence you had between vertices on the white and grey surface. This correspondence determines the shape of the "column" along which you sample your intensities. Smoothing the white surface without altering grey/pial coordinates can induce a shear in the trajectory on which you sample. The effect of this will be similar to the oblique electrode of Hubel and Wiesel, where you might measure different functional properties at different depths (https://goo.gl/images/b3bhLq).

The reason I smooth the areas a little is that with really high-res surfaces you can get tiny triangles that make for bad depth relationships.

Smoothing the mesh deals with (or introduces) addresses bad surface placement, smoothing the area values minimizes the impact of bad vertex distribution.

Please let me know if any of that isn't clear

Konrad

** A way to explicitly test that this is the case would be to measure cortical thickness with the raw and smoothed white surfaces and see whether the thickness is particularly increased in the gyri.

On 2018-04-10 21:36, Mark Lescroart wrote:

If I am reading kwagstyl's post right, it sounds like s/he is leaning towards using the smoothed surfaces, yes? I'm in favor of this, because I'd be afraid that the un-smoothed surfaces would be overfit to an individual anatomical scan. I know that some (many?) of the surfaces we have in use are from an average of 2 or more anatomical scans, but even so - there are still voxels, and thus I would fear that the un-smoothed surfaces would conform too tightly to an artificial rectangular grid. I suspect that if you were to coregister a new anatomical scan to the one used for generation of the surface (whether that is an average or not), and project that data onto the surface, the smoothed surface would give better results. Thoughts, @alexhuth [1] ?

Re: all else, this sounds like a smarter way to do things, and none of my pipelines (nor any that I am aware of in glab) would seem to be strongly affected by the proposed changes. So I'm for it.

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [2], or mute the thread [3].

*

Links:

[1] https://github.com/alexhuth [2] https://github.com/gallantlab/pycortex/issues/262#issuecomment-380238167 [3] https://github.com/notifications/unsubscribe-auth/ATLTxnQsM9sjCE1fKJPNwZAHejrLPggFks5tnRfOgaJpZM4S9C7q