layerfMRI / LAYNII

Stand alone fMRI software suite for layer-fMRI analyses.
BSD 3-Clause "New" or "Revised" License
85 stars 25 forks source link

Using LAYNII on FreeSurfer outputs and a columns question #13

Closed dangom closed 1 year ago

dangom commented 4 years ago

Hi again guys,

first of all thanks for sharing and developing LAYNII out in the open.

I've been playing with depth dependent analysis of my 0.9mm iso BOLD task data by upsampling my data 3x and then computing 3D volumetric masks for 10 layers using a combination of freesurfers' mris_expand and mris_fill, and FSL's fslmaths. That's been working OK for me as these tools work directly on the output of recon-all, such that most of my pipeline works automatically -- provided recon-all generates good surfaces and I manage to properly register my functional to the anatomy.

I would like, however, to not only compare signals across layers, but to constrain the comparison to columns as well. I was wondering whether LAYNII could help me in that regard, and if not, whether you guys would have suggestions on how to proceed.

Btw, what exactly does the landmark.nii file refer to in LN_3DCOLUMNS?

ofgulban commented 4 years ago

Hi @dangom ,

Thanks for your questions.

  1. The landmark.nii corresponds to points of inflection (see Step 3 here, and you can inspect the example landmarks.nii files in our test_data folder. As far as I know this method is more easily applicable to 2D images or small 3D ROIs because generating the landmarks.nii would be really hard and possibly inaccurate for the whole brain.

  2. I assume you want to do whole brain analysis with layers and columns. In this case handling columns is not as straightforward as layers. We are looking into this problem and there are several solutions but I would say a user-friendly LAYNII program that can handle various cases is months away.

  3. You can run LN2_LAYERS with -debug flag and have a look at *_columns.nii file (e.g. load it as a segmentation file in ITK-SNAP). This file gives you geometrically well-defined columns (explained here at step 3). Maybe you can come up with a creative way to make use of this output. These columns does not require you to define landmarks.nii which is good; but at the same time these columns are not ordered which might be bad depending on what you want to do.

Let us know how it goes, or if you have any insights, or new questions :)

layerfMRI commented 4 years ago

Hi @dangom,

That's an interesting direction. I guess, If you have good surfaces, and registrations from Freesurfer, I would honestly think that it might be most straightforward to stay in the vertex space. In this case, LAYNII might be solely a fallback option. Why shouldn’t u benefit from the vertex column definitions that come along with vertex space?

Different to layers, columns cannot be straightforwardly assigned with a single scalar number. Which makes it challenging to export them in 3D nifti files (the domain of LAYNII).

I guess you are aware of the description of LN_COLUMNAR_DIST here: https://layerfmri.com/columns/. This program estimates columnar distances from a single landmark based on a crawler algorithm: (exemplified here).

The program LN_3DCOLUMNS works analogously. The only difference is that it uses three landmarks to span a finite 3D grid. If you want to apply it in full 3D (e.g. as done in Fig. S3 here: https://doi.org/10.1016/j.neuroimage.2019.116463), you either need to use two sets of landmarks, or you use one of the nii-dimensions as an orthogonal direction (default is z-direction). I think Faruk’s (pessimistic) response that column definitions are inaccurate for the whole brain refers to this application.

These two programs solve the problem of assigning scalar column values by means of binning close voxels together along a certain direction. For whole brain analyses there is no predefined direction, and a different columnar definition might be more appropriate.

In past LAYNII application of whole brain columnar analyses (e.g. Fig 5-6 here), each voxel got its own column assignment. We used the following column definition: For any voxel in a given layer X, it is determined which other voxel from layer X+-1 is the closest. Then which voxel from layer X-+2 is the closest, etc. At the end, each voxel has one closest neighbor of each other layer. And this collection of voxels is used as a column. This column definition does not consider that each voxel is only represented in one column, though. We are writing this column definition in 4D nifti files there the 4th dimension contains the coordinates of the respective columns. T=0 -> x-coordinate of closest voxel in layer 1 T=1 -> y-coordinate of closest voxel in layer 1 T=2 -> z-coordinate of closest voxel in layer 1 T=3 -> x-coordinate of closest voxel in layer 2 T=4 -> y-coordinate of closest voxel in layer 2 T=5 -> z-coordinate of closest voxel in layer 2 … …

Since this is not an established file format of scalar column assignments, (like the the scalar LN_COLUMN* programs), we didn’t push it into LAYNII just yet. If you would be interested in this kind of columnar assignment, please let us know. I think it is here and we could straightforwardly pack it in LAYNII. Just like the solution from Faruk in his point 3.), his definition of columns does not come along with topographical proximity definitions.

ofgulban commented 4 years ago

Hey @dangom , just remebered one of your initial questions. Have a look at our new program LN2_COLUMNS. No need for defining landmarks in this one, +you can easily determine how many columns you want to have. Might be useful to "constrain the comparison to columns as well" (from your initial message).

three_dim_text

dangom commented 4 years ago

Saw it yesterday on twitter. Brilliant work, looks amazing! Curious to see how it'll perform on small FOV and how the column indexing works. Will try it on my data and will report back soon!

ofgulban commented 4 years ago

Oh, thanks. The columns are not ordered spatially as I was not parametrizing the topology (to make it easily work for 2D to partial coverage cases, without using landmarks). However the algorithm is deterministic and subdivides the topology by maximally distant points.

I have kept the column id's in the order they are generated so for instance columns 1 and 2 are guaranteed to be maximally distant (see pure red & blue in the gif below). And column 3 would be maximally distant to 1 & 2 (see pure green in the gif below) So there is some sort of order embedded in the columns ids. I have a feeling that this is a useful property but did not think of how to leverage it further yet :).

two_dim

Anyway, hopefully helpful in some way, let us know if you have an issue or if it works at all :)

ofgulban commented 3 years ago

Just an update as I have remembered this issue (and a note to my future self):