[ENH] Clarify mask/dseg/probseg in common derivatives

[effigies]

This PR does the following:

1. Remove conceptual overlap of binary masks and binary dsegs by standardizing on mask and updating the example to show that a single ROI should be renamed to mask. I left it under dseg to make the connection plain, as I don't think anything would be gained by moving it to mask (which has an ROI example already). This follows a brief discussion with @Lestropie and @edickie in https://github.com/bids-standard/bids-specification/pull/265#discussion_r432818644/https://github.com/bids-standard/bids-specification/pull/265#discussion_r432874774.
2. I added a preface to segmentations (removing parcellation from the section title) to place a conceptual hierarchy of type (discrete vs probabilistic) and a subordinate consideration of representation (volume vs surface) and further that we are not currently specifying probabilistic surface segmentations. This follows a discussion with @Lestropie and @satra in [ENH] BEP 003: Common Derivatives #265 (comment). While there is a desire to specify here, I'm refraining from doing so. It can be added without breaking backwards compatibility in the future.
3. I also addressed @satra's [ENH] BEP 003: Common Derivatives #265 (comment) while here.

Please read and let me know what you think.

[oesteban]

Thanks for this, Chris. I left a few comments - the most relevant is whether discrete segmentations should be limited to one class per sample (I think they shouldn't)

[oesteban]

Suggested change

	A *segmentation* is a labeling of a spatial image with anatomical structures
	A *segmentation* is a labeling of the samples in a signal encoding a partition of interest
	(e.g., the spatial delineation of anatomical structures in a 2D or 3D image)

[oesteban]

the concept of segmentation is valid for 1D signals too. I'm fine having all of this under imaging for practical reasons (i.e., finalize a first release of derivatives), but the definition could/should be general (IMHO).

[effigies]

I find this suggestion really hard to parse.

Are there examples of 1D signals that will be segmented in neuroimaging that really motivates this? I can try to offer some wording that would cover those cases.

[Lestropie]

Epilepsy EEG markup where there are multiple different seizure types? This is coming from no familiarity with EEG BIDS whatsoever; it just came to mind.

Another might be a discrete fixel-based parcellation; but whether such data are 1D or 4D is a matter of perspective 🙃

[edickie]

Most is good. But the use of the work "tissue" throughout the description of dseg might get confusing for those trying to apply the "dseg" suffix to the concept of "parcellations" where we are within one tissue class. (i.e. parcellations of the cortical surface, or aseg - parcellations of difference anatomical subcortical gray matter regions...).

Either we need to bring back "dparc" for parcellations...or come up with some more generic language than "tissue" ... what about "anatomical label" - referring to anatomical subdivisions, parcellations or tissue classes?

[effigies]

@edickie @oesteban Thanks for the feedback! I applied your suggestions RE labels for masks, and tried to move from "tissue class" to "anatomical structure". Let me know what you think.

[Lestropie]

Sorry, I'm gonna poke at this again 😬

This is technically another location where there are two different concepts getting mushed together (yes, that is the technical term):

• How are multiple segmented structures represented in a single file?
  • Within a single volume
  • Across volumes
• What data type is used to represent the segmentation?
  • Binary
  • Floating-point

For continuous / "probabilistic" data, storing multiple structures in a single volume is impossible, and so necessitates storing them across volumes.

For discrete data, we're accustomed to such being represented in a single volume / frame, using unique integer labels. This however enforces a one-to-one mapping between "elements" (e.g. voxels, vertices) and labels. In some instances (TractSeg comes to mind, as well as internal developments here), it's possible for one voxel to be included in multiple binary segmentations, at which point using unique integer labels does not work and one would need a 4D image.

(In a way this could be thought of as a 4D _mask.nii[.gz] image as opposed to / in addition to a _dseg image...)

I don't actually have a fixed opinion on what to do here (if anything); just seeing if the spec can be made to cover the fundamentals, rather than unnecessarily excluding anything that strays slightly from the current most common use cases.

[Lestropie]

Suggested change

	See [Anatomical Labels](#anatomical-labels) for interpretation how integer values
	map to anatomical structures.
	See [Anatomical Labels](#anatomical-labels) for interpretation regarding how
	integer values map to anatomical structures.

[Lestropie]

Suggested change

	structure with values ranging from 0 to 1 in individual 3D volumes or across
	structure with values in the range `[0.0,1.0]` in individual 3D volumes or across

(trying to indicate the the indicated range is inclusive of the bounding values)