Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged

Conversation

effigies
Copy link
Collaborator

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.

Copy link
Collaborator

@oesteban oesteban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)


Common JSON metadata fields:
A *segmentation* is a labeling of a spatial image with anatomical structures
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🙃

src/05-derivatives/03-imaging.md Outdated Show resolved Hide resolved
src/05-derivatives/03-imaging.md Outdated Show resolved Hide resolved
src/05-derivatives/03-imaging.md Outdated Show resolved Hide resolved
src/05-derivatives/03-imaging.md Outdated Show resolved Hide resolved
src/05-derivatives/03-imaging.md Outdated Show resolved Hide resolved
src/05-derivatives/03-imaging.md Outdated Show resolved Hide resolved
Copy link
Collaborator

@edickie edickie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator Author

@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.

@effigies effigies mentioned this pull request May 31, 2020
5 tasks
@effigies effigies merged commit e0508a7 into bids-standard:common-derivatives Jun 1, 2020
@effigies effigies deleted the enh/no_binary_dseg branch June 1, 2020 18:13
Comment on lines +164 to +168
A *discrete segmentation* represents each structure with a unique integer
label.
A *probabilistic segmentation* represents each structure as values between
0 and 1 (inclusive) at each location in the image, and one volume/frame per
structure may be concatenated in a single file.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +190 to +191
See [Anatomical Labels](#anatomical-labels) for interpretation how integer values
map to anatomical structures.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Similarly to a discrete, binary segmentation, the label key can be used to
specify the corresponding structure.
Probabilistic segmentations of brain tissue represent a single anatomical
structure with values ranging from 0 to 1 in individual 3D volumes or across
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

@nicholst nicholst changed the title Clarify mask/dseg/probseg in common derivatives [ENHClarify mask/dseg/probseg in common derivatives Jun 13, 2020
@nicholst nicholst changed the title [ENHClarify mask/dseg/probseg in common derivatives [ENH] Clarify mask/dseg/probseg in common derivatives Jun 13, 2020
@nicholst nicholst mentioned this pull request Jun 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants