RFC-4: Clarify subject-local orientation and add layered-tissue vocabulary#528
RFC-4: Clarify subject-local orientation and add layered-tissue vocabulary#528thewtex wants to merge 4 commits into
Conversation
Address review 3 (Dave Horsfall / Hannifa Lab, ome#435). Add a "Subject-Local vs. Patient-Global Orientation" clarification explaining that the orientation "subject" may be a local tissue structure (e.g. a biopsy or histology slide) rather than a whole organism. This makes the field applicable to spatial transcriptomics and histopathology without requiring whole-organism or atlas registration. Expand the anatomical controlled vocabulary with six terms for layered and polarized tissues: - superficial-to-deep / deep-to-superficial (skin, gut, cortex) - apical-to-basal / basal-to-apical (epithelial layers, polarized cells) - apex-to-base / base-to-apex (organs such as the heart or lungs) The values are added consistently to the LinkML source (orientation.yml) and its derived artifacts (orientation.schema.json, orientation.py, orientation.ts, markdown/AnatomicalOrientationValues.md) and to every representation embedded in index.md (vocabulary list, permissible-values table, JSON-Schema, Pydantic, and TypeScript). The now-redundant "histological: basal/apical" future-domain example is removed, since those values are now part of the anatomical vocabulary. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Automated Review URLs |
|
@davehorsfall @melonora @dyf please take a look 🙏 @jo-mueller I also added the null / undefined explicit mention as we discussed. |
|
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: |
An axis with no `orientation` field and an axis with an explicit `"orientation": null` are equivalent: in both cases the orientation is undefined, with no implicit default. This matches the OME-Zarr convention that only fields which are present carry meaning, and the reference implementation's behavior of culling a null orientation rather than serializing it. Add the clarification to the "Default Value" section and a changelog entry referencing fideus-labs/ngff-zarr#523. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/ngff-weekly-dev-update-thread/110810/105 |
|
Just to put it on record, I discussed this with @thewtex on zulip, the idea of local tissue orientation vs orientation of the tissue within the anatomical body can be seen as a primary orientation vs secondary orientation. We discussed this alternative and while there are emerging examples we agree it would be an overkill for now. Just to clarify by one example, there are labs doing whole body tissue clearing to perform lightsheet microscopy. Afterwards, from regions of interest biopsies are taken and subjected to highly multiplexed protein imaging. While these biopsies have a local orientation, they also have a secondary orientation in the whole body. @thewtex shall we add this to alternatives discussed? |
|
i think you can make the anatomical direction information robust by framing it as an annotation for a vector, where the only supported vectors right now are vectors that point in the direction of the coordinate axes. If ome-zarr gets formal support for geometrical objects like vectors, then images could use the anatomical direction information to annotate these vectors in ways that make sense for the contents of the image, e.g. an image of multiple organs, or multiple organisms, where anatomical orientation only makes sense locally |
Per the most recent PR ome#528 discussion, clarify that the orientation field describes a single, primary (subject-local) orientation and that additional/secondary orientations (e.g. a biopsy's position within the whole donor body) are not supported at this time. Note that if a generic vector data structure is added to OME-Zarr, these orientation annotations could be applied to such vectors, allowing multiple orientations where anatomical orientation only makes sense locally. Record the primary-vs-secondary modeling decision in the alternatives section and add a changelog entry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@melonora @d-v-b thanks both — I've captured these points in the RFC text in a follow-up commit:
|
Per the most recent PR ome#528 discussion, clarify that the orientation field describes a single, primary (subject-local) orientation and that additional/secondary orientations (e.g. a biopsy's position within the whole donor body) are not supported at this time. Note that if a generic vector data structure is added to OME-Zarr, these orientation annotations could be applied to such vectors, allowing multiple orientations where anatomical orientation only makes sense locally. Record the primary-vs-secondary modeling decision in the alternatives section and add a changelog entry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bb7addb to
3912bce
Compare
Co-authored-by: Wouter-Michiel Vierdag <w-mv@hotmail.com>
Follow-up to RFC-4 review 3 (Dave Horsfall, Hannifa Lab; added in #435), implementing its two accepted recommendations. The review was generated from a Hannifa Lab discussion spanning wet-lab scientists, clinicians, bioinformaticians, and engineers, and recommended "Accept, with minor changes: explicitly support subject-local orientation and expand the vocabulary to include layered-tissue terms."
What changed
1. New "Subject-Local vs. Patient-Global Orientation" clarification (
rfc/4/index.md)Clarifies that the orientation subject need not be a whole organism — it may be a local anatomical structure such as a tissue biopsy, histology slide, or dissected organ. The existing "roughly aligned to the imaging axes" requirement is reinterpreted to apply to the local tissue structure, and RFC-5 transformations are cited for relating subject-local axes to a patient-global / atlas frame when such a registration is available.
2. Six new controlled-vocabulary terms for layered and polarized tissues (anatomical vocabulary grows 18 → 24 values)
superficial-to-deep/deep-to-superficialapical-to-basal/basal-to-apicalapex-to-base/base-to-apex3. Removed the now-redundant
histological: basal/apicalfuture-domain example, since basal/apical are now part of the anatomical vocabulary.Why
In spatial transcriptomics, histopathology, and high-resolution histology, the imaged subject is frequently a tissue specimen whose global position/orientation on the donor is unknown, but whose internal orientation is well defined — e.g. a skin biopsy's depth axis is
superficial-to-deepregardless of where on the body it was taken. The prior wording was geared toward whole-patient imaging; these changes make theorientationfield usable by the tissue-profiling community without requiring full patient-to-atlas registration, and supply the layered/polarized-tissue terms that community needs.Implementation details
rfc/4/orientation.yml) and propagated consistently to every derived artifact —orientation.schema.json,orientation.py,orientation.ts,markdown/AnatomicalOrientationValues.md— and to every representation embedded inindex.md(controlled-vocabulary list, permissible-values table, JSON-Schema, Pydantic, and TypeScript snippets). A new "layered and polarized tissues" category was added to the vocabulary list and a2026-06-03changelog entry references review 3.1.11.0) diverges from the committed output (1.7.0) and regeneration would have introduced unrelated abstract-class/version noise. The updatedorientation.ymlwas nonetheless verified to still generate cleanly through LinkML (all six values present, no errors).rfc/4/versions/was intentionally left untouched.Verification
.py/.ts/.json; hyphenated values vs. underscored identifiers correct.orientation.schema.jsonis valid JSON,orientation.ymlvalid YAML,orientation.pycompiles, and the RFC page parses under MyST with no new errors.codespellclean; CodeRabbit review reported 0 findings.Out of scope
Review 3's third discussion point — a deeper RFC-4 ↔ RFC-5 semantic bridge for programmatic atlas registration — is left for future collaboration, as the reviewer suggested. The RFC's existing "Interaction with RFC-5" section already covers the basic relationship.