Hi Judd,

thanks for thinking with me about this masking idea.

Judd wrote:

> If these masks have been generated based on a moving
> neighborhood, would it be important to have access to the
> intended "center" of the neighborhood?
>
> It seems likely that if the shapes of the neighborhoods have
> been processed a lot then the "center" of the neighborhood
> might not be obvious anymore when working backwards from only
> the binary mask. This could possibly be a problem when trying
> to create a map of the output.

It depends on how you define your ROIs. Consider three different scenarios:
1) the traditional approach: each ROI is sphere-sized (or a subset of a sphere, if we mask out grey matter) and their centers consist of the set of voxels in the brain in the original functional data; as you mentioned, there is a injective but not surjective mapping from functional voxels to ROIs
2) high-res mapping: centers of the ROIs are voxels in a high-res image (say a T1). In this case we have many more ROIs than voxels in the original dataset.
3) surface mapping: suppose we have a surface map, then we define an ROI in the neighbourhood of each node on the surface (I'm currently assessing on this approach).

While your idea would work for (1) and possibly for (2), it would not work for (3) and may not work for other ROI definitions. I think it would be preferable to keep the mapping from "intended center" to ROI separate from the actual ROI definition.

In (1) this could possibly be achieved be achieved by storing the ROI number in each voxel (or negative if no ROI is associated with it), in a standard .HEAD/.BRIK file; similar to your spatial offset mask. It seems that brick_type=2 (int) values are not supported yet, but floats should probably be good enough for at least 1e6 ROIs. Or we could store a file with unsigned ints as you suggested.
For (3) this would typically be stored in a .1D file.

Finally, if you want to keep the mapping from voxels to ROIs stored in (1), you could decide that for each ROI definition the first voxel index corresponds to the center voxel. Not very elegant though.

Does that make sense?

> So here's a different idea:
>
> If each location in space maps to at most one mask, then
> another idea
> would be to create a BRIK as a 3D image plust trailing binary
> data. [...]
>
> In theory you could store any voxel wise data not only masks.

Well, these sparse masks are binary, and therefore in the current proposal we don't store the data associated with the voxels (why store only ones). Of course you could extend the idea to allow for storing data as well, but I'm afraid that will complicate things further.

best,
Nick