clearly defined anatomical orientation

[dyf]

The anatomical orientation of an array is a critical piece of metadata for downstream analysis, particularly for the increasingly common task of aligning acquired images to an atlas for anatomical quantification and standardized comparison to other data.

Currently the NGFF spec includes coordinate transformations, but the anatomical orientation of the sample once the transformation is applied is unspecified. As a result, tools simply make assumptions about orientation, which leads to wasted time and erroneous results. In systems with a fair amount of anatomical symmetry like the brain, it is impossible to retroactively inspect data to understand the orientation in which it was acquired. A place in the spec where we are explicit about anatomical orientation will allow acquisition and analysis tools to stop making assumptions.

I propose we add a field with a controlled vocabulary for anatomical orientation. Some prior art:

The ITK ecosystem uses 3 letter acronyms to describe anatomical orientation. For example RAS corresponds to:

• the first axis increases from left to Right
• the second axis increases from posterior to Anterior
• the third axis increases from inferior to Superior

This works, however the acronyms are ambiguous. I personally continually have to look up if R is left-to-right or right-to-left.

Nifti's coordinate transforms are assumed to map data into RAS. This approach also works, however it relies on users and data generators being familiar with the Nifti spec and abiding by it.

The Brain Image Library asks for a more explicit definition of anatomical orientation. Submitters choose for each axis from a controlled vocabular that resembles the following:

• left-to-right
• right-to-left
• anterior-to-posterior
• posterior-to-anterior
• inferior-to-superior
• superior-to-inferior

We have adopted this at the the Allen Institute for Neural Dynamics in our data schema. We may consider adding dorsal-to-ventral, ventral-to-dorsal, rostral-to-caudal, and caudal-to-rostral to this vocabulary.

At the recent Get Your Brain Together hackathon hosted at the Allen Institute this was discussed at length.

Please consider adding an anatomicalOrientation field to axes metadata. Because this would be a controlled vocabulary, I recommend separating it from longName, which is uncontrolled (see #142). I am of course also open to this living elsewhere.

Should this have a default, I suggest it be RAS to be consistent with Nifti.

[d-v-b]

@dyf thanks for raising this important issue! I think what you are describing could be expressed via the coordinateSystem semantics defined over in #138, have you had a look at that PR?

If you have imaging data in the condition where it was acquired / stored in instrument coordinates, but can be transformed to anatomical coordinates via some transformation, you basically have two coordinateSystems, and your controlled vocabulary could be used for the names of the axes in the my_reference_brain coordinateSystem.

"coordinateSystems" : [
                {
                    "name" : "instrument",
                    "axes": [
                        {"name": "z", "type": "space", "unit": "micrometer"},
                        {"name": "y", "type": "space", "unit": "micrometer"},
                        {"name": "x", "type": "space", "unit": "micrometer"}
                    ]
                },
                {
                    "name" : "my_reference_brain",
                    "axes": [
                        {"name": "anterior-to-posterior", "type": "space", "unit": "micrometer"},
                        {"name": "inferior-to-superior", "type": "space", "unit": "micrometer"},
                        {"name": "left-to-right", "type": "space", "unit": "micrometer"}
                    ]
                }
            ],

The transformation from one coordinateSystem to the other would be contained in different metadata, as per #138. (@bogovicj please correct me if I'm getting anything wrong here)

Would this work for you @dyf ?

[bogovicj]

Yup, the way @d-v-b described is how I had in mind to describe anatomical coordinates using the v0.5 spec - coming soon.

[jcfr]

The ITK ecosystem uses 3 letter acronyms to describe anatomical orientation.

Timely discussion as we just migrated the content of the wiki page to Read the Docs.
See https://slicer.readthedocs.io/en/latest/user_guide/coordinate_systems.html

cc: @lassoan @pieper @muratmaga

[d-v-b]

@dyf wrote

Please consider adding an anatomicalOrientation field to axes metadata. Because this would be a controlled vocabulary, I recommend separating it from longName, which is uncontrolled (see #142). I am of course also open to this living elsewhere.

Regarding anatomicalOrientation, for my data (images of cells and tissues), this concept would be meaningless, and I think that's a red flag as far as putting this in spec is concerned. I think we should try to avoid adding metadata that only applies to one subdomain of imaging -- (you might reasonably have the same response if I proposed coverSlipDirection metadata, or anything else that was specific to the details of how my images are produced).

In that vein, your point about longName being uncontrolled is interesting. Note that there is nothing stopping the community of neuroimaging scientists from introducing their own refinement of ome-ngff that restricts the type of longName from string to a concrete subtype of string, such as your controlled vocabulary. This might even be a better outcome for you, because then you are free to evolve your controlled vocabulary without first needing to change the ome-ngff spec. For example, your specification could state "image data must be stored as ome-ngff, with the following extra constraints on the names of axes.... etc". I think that's a solid general solution to problems unique to subdomains of imaging -- those communities can "subclass" the spec and add extra domain-specific constraints as needed. As long as the resulting ome-ngff files are consistent with the main spec, this seems like a good outcome.

[dyf]

Wow, amazed at the quick response, thanks all!

How about a more domain-agnostic name? e.g. direction, orientation or physicalOrientation?

That said, I'm open to putting this into an extension (e.g. an anatomy or neuroanatomy extension). It's most important (to me) that downstream applications know what terms to expect and how they are defined, so either in the core spec or an easily discoverable extension would be fine.

Pardon my ignorance - is there an extension mechanism already?

[joshmoore]

In talking to the good folks of Get Your Brain Together (late one night), I proposed either as part of the existing coordinate system or perhaps by having a dedicated subclass of existing systems, the ability to add a field that is defined by an enum or ontology that is managed by a community outside of the NGFF process.

The "name" fields in the above examples could almost be used for these purposes but issues such as:

• namespace collision with other communities
• need for multiple coordinate systems of the same type

could benefit from having additional type information that the medical community can detect and "do the right" with. I think the question is whether this should be a specifically anatomical extension, or if there's a way to add this type information more generically.

(Oops. Comments were added while I was writing. I think nonetheless that this holds. I don't think names are sufficient alone. Another possible option would be a prefixing mechanism that is community-specific, but this would likely become unwieldy.)

[dyf]

@joshmoore I agree that names are insufficient for the reasons you say.

Adding a new field that refers to an enum/ontology would be great. Different communities would be able to use different controlled terms by indicating what ontology they use. Validation may get tricky, but it's at least a start.

I this orientation might be a good generic term that others could use for similar purposes.

[d-v-b]

I had a look at how the CF conventions handles this: https://cfconventions.org/Data/cf-conventions/cf-conventions-1.10/cf-conventions.html#standard-name. As I understand it, a physical quantity (like length) can be associated with a standard_name field, which is basically used as a lookup into a collection of standard quantities. Materially, this would result in metadata like:

{
    "name" : "my_reference_brain",
    "axes": [
        {"name": "a-p", "standard_name": "anterior-to-posterior", "type": "space", "unit": "micrometer"},
        {"name": "i-s", "standard_name": "inferior-to-superior", "type": "space", "unit": "micrometer"},
        {"name": "l-r", "standard_name": "left-to-right", "type": "space", "unit": "micrometer"}
    ]
}

I think the standard_name field would have to be nullable, because there's plenty of communities that don't have strict semantics for axes. In the case of CF, the CF metadata standard itself includes a reference to the list of standard_name values. Unless we want to do something similar (i.e., bake these names into an ome-ngff-adjacent standard), there might need to be an additional piece of metadata that links out to a resource / authority that defines the semantics of "anterior-to-posterior".

@joshmoore said:

The "name" fields in the above examples could almost be used for these purposes but issues such as:

namespace collision with other communities
need for multiple coordinate systems of the same type

Can you elaborate on these concerns? I don't really understand how namespace collision with another community would be a problem -- presumably all that matters is that community X can save and load their data. If community Y uses the same metadata names as X, why is that bad? Perhaps I'm missing something. And I didn't understand the second concern at all.

[dyf]

I like adding a standard_name field along with a clear way to refer to an outside ontology. I would prefer an additional field for this (rather than a prefix). I would be happy to find or create an ontology we could refer to via URI.

I can't speak for @joshmoore, but for me a primary goal is to remove undocumented assumptions so that tools can reliably interpret the orientation of images. If multiple subcommunities have different, disparately (or un-) documented conventions for how to interpret name, then the situation is still muddled.

[joshmoore]

@d-v-b Can you elaborate on these concerns? I don't really understand how namespace collision with another community would be a problem -- presumably all that matters is that community X can save and load their data. If community Y uses the same metadata names as X, why is that bad?

I was primarily referring to collisions either on the namespace prefix itself or on the key if there is no namespace prefix. What's bad is if community X and Y cannot tell if the data came from the other community.

@d-v-b And I didn't understand the second concern at all.

I may have misunderstood @dyf's example, but if detection is based on the use of a unique value as the name, then that coordinate system can only exist once. i.e., let's not overload name with multiple responsibilities -- currently it is for unique look up of the coordinate systems, and I don't think it should also be responsible for determining orientation (or other metadata that could be requested in the future).

@dyf I like adding a standard_name field along with a clear way to refer to an outside ontology. I would prefer an additional field for this (rather than a prefix). I would be happy to find or create an ontology we could refer to via URI.

In my opinion, standard_name is not really descriptive of what we are looking for. I also agree that prefixes aren't ideal. And I'm not sure we should limit to a hard-coded ontology (i.e. it should be extensible), but 👍 for @dyf & co. finding or creating an ontology that works for their purposes.

[d-v-b]

I think this issue relates to #203, insofar as we are thinking about giving a "proper name" to a measurement / quantity (anatomical coordinates can be thought of as special lengths).

Depending on how big the ontology is going to be, I wonder if we should consider requiring that it be versioned and stored inside the zarr metadata under the appropriate namespace (maybe under an ome.ontologies key in the container root?). This would make the data self-describing and make things much easier for parsers (i.e., you should be able to validate without an internet connection).

[pieper]

It would be great to be able to use dicom headers for lossless conversion between ome-ngff and WSI or other dicom objects. A lot of the concepts mentioned in this thread already have well standardized representations in dicom and it would be a shame to devise something from scratch that duplicates the concepts in an incompatible way. I know a lot of people think dicom is complex and hard to use, but in my experience it's the data that's complex and so any standard will be complex and we might aw well use the one we have.

It may not be realistic to assume that everyone will use dicom, but the ability to losslessly transcode between formats seems like a very valuable goal.

[dyf]

@d-v-b I think this issue relates to #203, insofar as we are thinking about giving a "proper name" to a measurement / quantity (anatomical coordinates can be thought of as special lengths).

Yes, we put axis units next to anatomical orientation in our metadata schema.

@d-v-b Depending on how big the ontology is going to be, I wonder if we should consider requiring that it be versioned and stored inside the zarr metadata under the appropriate namespace (maybe under an ome.ontologies key in the container root?). This would make the data self-describing and make things much easier for parsers (i.e., you should be able to validate without an internet connection).

It's quite small. I would love to be able to include it here so that we can use it for validation.

[joshmoore]

d-v-b commented 4 days ago
I think this issue relates to #203, insofar as we are thinking about giving a "proper name" to a measurement / quantity (anatomical coordinates can be thought of as special lengths).

I wonder if meaning or interpretation are starting to approach what you are getting at.

d-v-b commented 4 days ago
Depending on how big the ontology is going to be, I wonder if we should consider requiring that it be versioned and stored inside the zarr metadata under the appropriate namespace (maybe under an ome.ontologies key in the container root?). This would make the data self-describing and make things much easier for parsers (i.e., you should be able to validate without an internet connection).

That might make things more self-describing for humans but not for the programs that will need to understand a priori. Further, if this is a general mechanism that we want to use for the interpretation of other fields in the future, I fear the inlining burden will become burdensome.

dyf commented 3 days ago
It's quite small. I would love to be able to include it here so that we can use it for validation.

What do you mean by "include it here", @dyf? i.e. in this issue?

pieper commented 3 days ago
It would be great to be able to use dicom headers for lossless conversion between ome-ngff and WSI or other dicom objects. A lot of the concepts mentioned in this thread already have well standardized representations in dicom and it would be a shame to devise something from scratch that duplicates the concepts in an incompatible way. I know a lot of people think dicom is complex and hard to use, but in my experience it's the data that's complex and so any standard will be complex and we might aw well use the one we have. It may not be realistic to assume that everyone will use dicom, but the ability to losslessly transcode between formats seems like a very valuable goal.

💯 for working towards interoperability, @pieper. Can you show a snippet of what you think that header information would look like?

dyf commented 3 days ago

@d-v-b I think this issue relates to #203, insofar as we are thinking about giving a "proper name" to a measurement / quantity (anatomical coordinates can be thought of as special lengths).

Yes, we put axis units next to anatomical orientation in our metadata schema.

Can you share an example of that, @dyf? I think working towards a collection of N similar json blurbs that encode the same information that we can start referring to by name for this discussion would be useful.

[d-v-b]

@joshmoore

d-v-b commented 4 days ago
I think this issue relates to #203, insofar as we are thinking about giving a "proper name" to a measurement / quantity (anatomical coordinates can be thought of as special lengths).

I wonder if meaning or interpretation are starting to approach what you are getting at.

Hmm.. these are a bit subjective, no? I feel like standard_name or ontology_identifier are a lot more explicit. But I think picking the right field name(s) would be a lot easier if we had examples of the ontology data referenced by those fields.

d-v-b commented 4 days ago
Depending on how big the ontology is going to be, I wonder if we should consider requiring that it be versioned and stored inside the zarr metadata under the appropriate namespace (maybe under an ome.ontologies key in the container root?). This would make the data self-describing and make things much easier for parsers (i.e., you should be able to validate without an internet connection).

That might make things more self-describing for humans but not for the programs that will need to understand a priori. Further, if this is a general mechanism that we want to use for the interpretation of other fields in the future, I fear the inlining burden will become burdensome.

I think the alternative to making a dataset self-describing is to use links, but links can break, either because the content at the URI has moved, or because internet connectivity is unreliable. I'd be a a little uncomfortable requiring an internet connection for validating an ome-ngff with ontologies in it, at least if the ontology information is small enough to fit in JSON. Hopefully an example ontology document can clear up some of these issues.

[dyf]

@d-v-b I want to include the terms that are in the issue (e.g. anterior-to-posterior). So, it would be 6-8 terms in a JSON file. We could extend it if needed.

If you are looking for a relevant external source, see:

https://openminds.ebrains.eu/v3/ --> controlledTerms -> anatomicalAxisOrientation.

They describe each term in jsonld, e.g.: RAS, RAI.

The difference is that I am asking for these 3-letter codes to be broken up so we can describe each axis clearly and independently (rather than assume that all arrays are 3-dimensional).

We could very easily package these terms up into a JSON file and add them to the repository.

[dclunie]

FYI, the DICOM coordinate systems and orientations may be relevant when something is patient-relative.

The co-ordinate system is used when the origin of an image TLHC and the unit vectors defining the orientation of the rows and columns of an image are to be described. DICOM is +ve in the LPS (left-posterior-superior) directions.

For 2D images (such as a mammogram) the row and column directions of an image are defined in a patient-relative sense categorically.

These are described at:

• https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.2.html#sect_C.7.6.2.1.1
• https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.html#sect_C.7.6.1.1.1
• https://dicom.nema.org/medical/dicom/current/output/chtml/part17/chapter_A.html

Note that quadrupeds as well as bipeds are accounted for (theoretically).

See also this (outdated) explanation:

• https://www.dclunie.com/medical-image-faq/html/part2.html#DICOMOrientation

There are also (US) volume-relative and slide-relative coordinate systems:

• https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.24.2.html#sect_C.8.24.2.1.1
• https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.12.2.html#sect_C.8.12.2.1.1

[dyf]

Do folks have an opinion on the format and location of the controlled vocabulary? I am planning to open a draft PR for this in the next week or so.

[lassoan]

It would be nice if the file format could store standard coded entry data as specified in the DICOM standard (and used in all clinical imaging applications). You can find all the intricate details in the DICOM standard, but in practice it is quite simple - an entry is specified by these 3 strings:

• coding scheme: name of the coding scheme (e.g., SCT = Snomed Clinical Terms, FMA = Foundational Model of Anatomy, ...)
• code value: identifier specified in the coding scheme (usually not a human-readable term, but some alphanumeric code)
• code meaning: optional human-readable description (for example, it can be displayed for the user if the application does not know the term)

[pieper]

+1 to @lassoan's suggestion of adopting the (scheme, value, meaning) code tuple concept from DICOM. Another feature of it is that in addition to standardizing references to useful vocabularies like SCT and FMA, anyone can designate custom vocabularies by prefixing the scheme with 99 as a flag that it's non-standard. So there's flexibility to support research use cases.

[pieper]

Did all the talk of DICOM derail this conversation?

I would like to encode some microCT data that is currently in nrrd format and I'm curious if anyone has settled on a convention for storing the 'space-directions' and related metadata.

From what I can see the ITK implementation only stores spacing and origin.

If there is no existing convention I'll be glad to make up my own.

[thewtex]

@pieper If I understand what you are looking for, identification of axes and whether they refer to a spatial dimension or not, is already defined in v0.4 of the spec.

Transformations that would support flips of axes are being added in #138

[thewtex]

I took the liberty to:

• Write up the controlled vocabulary
• Summarize the discussions so far
• Collect in the new RFC process format
• Write a LinkML definition

in #253

[pieper]

@thewtex thanks for working on that PR 👍

I do have a comment that I'm not sure whether to put here or there, but I'll start here and if people agree it's worth addressing we could try to adapt the PR.

My issue is that the PR as currently written assumes that the imaging axes will always be along one of these defined anatomical directions (e.g. right-to-left or rostral-to-caudal). While this is often the case, it's also likely that the imaging will be rotated with respect to these axes, or even sheared for some scan types. This is where the concepts in nrrd of 'space' and 'space directions' are useful. What you have already documented would be really good for the definitions of the space axes, while the definition of a vector-per-axis direction to define the trajectory of a given axis through the physical space.

These situations come up frequently in medical imaging, for example MRs acquired on a tilted plane, or CTs with a shear due to gantry tilt. But they can also arise if microscopy images need to be spatially correlated with macroscopic anatomy.

I'm afraid I find it hard to follow the discussion in this PR related to transforms, but my fear is that if we don't have a clear way of describing common image acquisition geometries then the logic around transforms will end up with extra complexities.

[lassoan]

As I understand, the ngff file will define multiple coordinate systems and transforms between them. ITK will specify "image" and "physical" coordinate systems and an affine transform between them. Each axis of the "physical" coordinate system axes will have anatomicalOrientation property.

[pieper]

ITK will specify "image" and "physical" coordinate systems and an affine transform between them

Yes, I agree that's how it should work, but when I read the current pr text it doesn't come across that way. To me it says that if, for example, you had a coronal acquisition you would define that using the anatomicalOrientation fields of the axis descriptions, not via a transform applied within a reference space.

Maybe we can have worked out examples for common imaging scenarios so that it's clearer how these anatomical labels and transforms should be used together. To me, it's good for the information about anatomical mapping to be included in the transform, while the low level pixel container only talks about memory layout. I.e. at the zarr level you are only talking about rows, columns, slices, blocks, etc. But then the transform introduces the idea that you are mapping from these indices into a particular physical space (such as "LPS" or "RAS").

To say it another way, the concept of "inferior-to-superior" should exist within the transform to physical space, not as a label assigned to the z axis of a data array.

[lassoan]

axes will refer to axes of coordinateSystems (not axes of the image) as soon as #138 is merged

[pieper]

Okay, sounds like the right direction. I'll take another look when all this stuff is merged.

[fcollman]

"Regarding anatomicalOrientation, for my data (images of cells and tissues), this concept would be meaningless, and I think that's a red flag as far as putting this in spec is concerned. I think we should try to avoid adding metadata that only applies to one subdomain of imaging -- (you might reasonably have the same response if I proposed coverSlipDirection metadata, or anything else that was specific to the details of how my images are produced)."

I think that there are two issues here, one that is completely general and one that is domain specific.

The general one is that the current proposal leaves it up to interpretation which axes correspond to what directions in space, and how those axes are oriented. There are some conventions in how data is laid out with respect to space, but there are many variations. 1. 'matrix' like order, with up/down followed by left/right and increasing values in "up/down" reflecting going downward on a 2d page, and increasing values of "left/right" indicating rightward. When dealing with Z, some people follow on the convention and put the third axis (toward/away) in front of the others, some people place it last. Many follow the right hand rule, but others don't. The other is 'axes' style where 'left/right' is followed by 'up/down', and then 'in/out' comes last. Most would follow the convention that higher values represent right, up and in.

This specific one relates to domain specific schemas about what the interpretation of these physical orientations are, and the reasonable desire for communities to have shared interpretations of those physical orientations. I think allowing the spec to let users specify more restrictive schemas (in the form of a pointer to a json_schema) would allow for readers to be able to identify data that could be trivially and reliably cross compared.

[d-v-b]

I think allowing the spec to let users specify more restrictive schemas (in the form of a pointer to a json_schema) would allow for readers to be able to identify data that could be trivially and reliably cross compared.

I agree, and fortunately there's nothing in the spec today that prevents this -- as far as I know, you are generally allowed to add extra metadata fields to all parts of OME-NGFF metadata. I don't think this is very common (I've never seen it) but it's certainly possible.

[thewtex]

I think we should try to avoid adding metadata that only applies to one subdomain of imaging

The anatomical orientation proposed here is not a "MUST always" be specified. If the image is one of cells or tissues without anatomical orientation, then anatomicalOrientation should not be specified.

Anatomical orientation is critical for domains that need it, and it should not be blocked for "it is not important to me" reasons. If coverSlipDirection is a critical piece of metadata, then it should be added to the spec so the community can preserve and understand that metadata. We already have information in the OME-Zarr spec related to high-content screening data. Not all OME-Zarr are high-content screening datasets, but it is beneficial to have it defined in the spec.

The general one is that the current proposal leaves it up to interpretation which axes correspond to what directions in space, and how those axes are oriented.

This spec is intended to work with the Coordinate systems and transformations spec, which addresses the issues mentioned. If there are gaps, please provide a proper review to this spec or RFC-5 that clearly lays out where the are issues are in the spec with demonstrations in implementations and use cases.

[lassoan]

The anatomical orientation proposed here is not a "MUST always" be specified

Exactly. Since anatomicalOrientation field is optional, this new field should not cause any problems for geo, astronomy, microscopy, etc. applications. We could define domain-specific fields in "extensions" (maybe in various other repositories), but this would lead to a more fragmented standard and implementations, and potential redundancies and additional complexity. If we can all tolerate being exposed to each others' domain-specific definitions then I think it is better to try to keep everything at one place.

It could be useful to define "profiles" to specify rules about which of the optional fields are required for what domain. For example, the radiology profile could specify that anatomicalOrientation field is required for images.

[fcollman]

This spec is intended to work with the Coordinate systems and transformations spec, which addresses the issues mentioned. If there are gaps, please provide a proper review to this spec or RFC-5 that clearly lays out where the are issues are in the spec with demonstrations in implementations and use cases.

Yes we are working on one collectively at the Allen! should be done in the next week or so.

[d-v-b]

I think we should try to avoid adding metadata that only applies to one subdomain of imaging

The anatomical orientation proposed here is not a "MUST always" be specified. If the image is one of cells or tissues without anatomical orientation, then anatomicalOrientation should not be specified.

Anatomical orientation is critical for domains that need it, and it should not be blocked for "it is not important to me" reasons. If coverSlipDirection is a critical piece of metadata, then it should be added to the spec so the community can preserve and understand that metadata. We already have information in the OME-Zarr spec related to high-content screening data. Not all OME-Zarr are high-content screening datasets, but it is beneficial to have it defined in the spec.

Making the anatomicalOrientation key optional does largely address my concern (which is that we are baking the conventions of a particular imaging subdomain into a spec that purports to work for all bioimaging). An alternative solution would be to change the name of the key from anatomicalOrientation to orientation, and open the key space so that coverSlipDirection could in fact be used under this key by a community of cell biologists.

My concern is that the fundamental problem you are trying to solve for neuroimaging is in fact common to all imaging modalities. It would be great if your solution could be generalized (e.g., was not overly specific). Perhaps this concern looks like I'm saying "it is not important for me", but IMO that's not a charitable summary, and to be clear I'm not trying to block anything, just posting feedback that hopefully leads to a refined solution.

[d-v-b]

We already have information in the OME-Zarr spec related to high-content screening data. Not all OME-Zarr are high-content screening datasets, but it is beneficial to have it defined in the spec.

Two wrongs don't make a right! I think special-casing the HCS layout was a mistake, and a much better solution would be to define a "collection of images spec" that could work for HCS and any other imaging dataset that needs to express structured collections.

[thewtex]

An alternative solution would be to change the name of the key from anatomicalOrientation to orientation, and open the key space so that coverSlipDirection could in fact be used under this key by a community of cell biologists.

The anatomicalOrientation and coverSlipDirection are orthogonal pieces of information, meaning they represent different and independent aspects of the data. For some datasets, a researcher may want to specify both. Therefore, it would be beneficial to keep them as separate entities rather than combining them into a single orientation field. This separation ensures clarity and precision in representing the data's attributes.

My concern is that the fundamental problem you are trying to solve for neuroimaging is in fact common to all imaging modalities. It would be great if your solution could be generalized (e.g., was not overly specific).

The RFC is not specific to neuroimaging, and it addresses both bipeds and quadrupeds.

Perhaps this concern looks like I'm saying "it is not important for me", but IMO that's not a charitable summary, and to be clear I'm not trying to block anything, just posting feedback that hopefully leads to a refined solution.

Constructive feedback is welcome.

Two wrongs don't make a right! I think special-casing the HCS layout was a mistake, and a much better solution would be to define a "collection of images spec" that could work for HCS and any other imaging dataset that needs to express structured collections.

I could not disagree more. The HCS (High Content Screening) layout is a valuable standard that addresses a real and pressing issue in the scientific community. It provides a concrete, well-defined solution for handling structured collections of images in high-throughput imaging experiments, which are increasingly common across many research domains. By standardizing how these datasets are stored and accessed, HCS not only ensures reproducibility but also facilitates interoperability between different tools and platforms used by researchers.

To suggest that special-casing the HCS layout was a mistake overlooks the practical benefits that it has already delivered. While the idea of a more general "collection of images spec" might sound appealing, it remains a vague and hypothetical alternative that has not been implemented, tested, or proven to work in real-world scenarios. Obstructing a concrete, widely-adopted solution in favor of an abstract possibility would only hinder progress and slow down the development of tools that scientists need today.

In practice, real-world problems require real-world solutions, and HCS fills that need effectively. If a more generalized solution is eventually developed, it can be integrated in the future, but dismissing HCS in its favor at this stage would be premature and counterproductive.

[d-v-b]

My concern is that the fundamental problem you are trying to solve for neuroimaging is in fact common to all imaging modalities. It would be great if your solution could be generalized (e.g., was not overly specific).

The RFC is not specific to neuroimaging, and it addresses both bipeds and quadrupeds.

For me the key question is whether bioimaging scientists who are not imaging bipeds and quadrupeds can use this spec to assign semantics to directions in their data. My read of the relevant RFC and the discussion here is that the answer to this question is "no", and it's up to specific communities to repeat the process here with their own key on axes metadata, and their own controlled vocabulary. E.g., scientists who study fruit flies and need to assign anatomical semantics to directions in their images would be recommended to handle that with something like a separate insectAnatomicalOrientation key in the axes metadata. Is this a fair summary?

To suggest that special-casing the HCS layout was a mistake overlooks the practical benefits that it has already delivered.

I don't follow this logic. The alternative to special-casing the HCS layout is not "no HCS layout", it's "define spec that allows users to define an HCS layout, but also non-HCS layouts". The practical benefits are greater in the latter case, because HCS users and non-HCS users can express their data models.

Maybe the word "mistake" is causing friction here? Apologies if that comes across as harsh -- I'm using the term to denote "technical debt we could have avoided with a bit more planning". Personally I think technical debt / mistakes are OK, and even inevitable in software; we should just endeavor to fix those mistakes. And there is an ongoing effort to define an image collections spec to address this issue.

[joshmoore]

Thanks everyone for the ongoing engagement. The introduction of (more) domain specific information is certainly a cause for care and applying previously learned lessons. I'm concerned, however, that this issue will grow without bound. In an attempt to wrap up it up, here are some thoughts on what's in-scope and out-of-scope from my point-of-view fir @thewtex's RFC:

In-scope

• Seconding @thewtex, reviews of the https://ngff.openmicroscopy.org/rfc/4/ are very welcome. Please do try to frame things though in terms of what changes would make you endorse the proposal.
• Of course, additional, even conflicting, RFCs are welcome if someone is so inclined.
• The one suggestion from above that might be worth considering is moving from anatomicalOrientation= "value" to orientation="anatomical:value" (or similar) to allow for application to other domains (orientation="insect:value". We will need to be careful that this does not overly expand the scope of RFC-4 since the prefix mechanism is not currently defined.

Out-of-scope

There were a few suggestions that I'd like to come back to, but elsewhere:

• extensions
• profiles
• and of course the collections proposal

If any of the above commentators is interested in driving an RFC for one of those, please get in touch! Otherwise, I'll make sure they are included on the overall roadmap.

Did I miss anything? Any final comments? Otherwise, I'd propose we close this issue, and charge ahead with RFC-4.

[muratmaga]

I will make some comments here, since I do not know how to make comments on the RFC:
dorso-ventral: Describes the directional orientation from the back (dorsal) to the front (ventral) of an anatomical structure or body. is incorrect. The back in here, is not referring to the posterior part of the body, but refers to the spine. Therefore, ventral is not referring to front, but refers to the abdomen (or belly colloquially). Referring dorsal as back and ventral as front is human (biped) specific.

I find the rostrum a questionable term as well. Correct term should be cranial.

Also are there any fish experts here to comment on the anatomical orientations discussed? Much like insects, they are neither bipeds nor quadrupeds.

[lassoan]

@muratmaga good catch! I guess it was just a not careful enough rephrasing of the DICOM standard (https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.2.html#sect_C.7.6.2.1.1).

I would remove the interpretation part (don't try to match "front" and "back" colloquial terms) and add all the directions that the DICOM standard defines. @muratmaga would these directions cover all the biology use cases that you are aware of?

• left-to-right
• anterior-to-posterior
• inferior-to-superior
• dorsal-to-ventral
• dorsal-to-plantar
• dorsal-to-palmar
• rostral-to-caudal
• cranial-to-caudal
• proximal-to-distal

The one suggestion from #208 (comment) that might be worth considering is moving from anatomicalOrientation= "value" to orientation="anatomical:value" (or similar) to allow for application to other domains (orientation="insect:value".

The DICOM standard does exactly this for terms when it is not possible to choose a single terminology that is suitable for all use cases. Each term is specified with a triplet: CodeValue (unique identifier for a term), CodingSchemeDesignator (identifier for the authority that issued this code), CodeMeaning (human-readable code description). In this case, it would look something like "orientation": [["DCM", "392933", "left"], ["DCM", "392944", "right"]]. However, in case of a widely-accepted set of limited terms are available, the extra flexibility of using any external terminology is not necessary, and it simplifies implementation if the allowed terms are listed explicitly in the standard.

Authors of the DICOM standard decided that for anatomical orientation they don't need to rely on external terminologies and they specified all the terms inside the DICOM standard. I believe the same choice would work well in the NGFF standard, too. The proposed anatomicalOrientation field name seems specific enough (calling it just orientation would be too broad, because there are other types of orientations, not just anatomical) and not too narrow (calling it dicomAnatomicalOrientation would be unnecessarily specific, as the terms should work well with all anatomical images).

If we introduce the anatomicalOrientation field, it is still possible to add a more generic orientation field in the future. The "radiology" profile could then specify if the more flexible generic orientation field and/or the simpler anatomicalOrientation field should be used by software that support that profile.

[muratmaga]

@muratmaga would these directions cover all the biology use cases that you are aware of?

Those look good for tetrapods, which I am mostly familiar with. Beyond that all I can say multicellular life has a lot of weird bodyplans (think of seahorses, echinoderms. I am sure plants have their own anatomical planes), which may require new axes definitions eventually. But this set should cover most of what frequently needed.

[thewtex]

Thanks to all for the discussion.

I emphatically agree with @joshmoore that identification of what is in-scope here and out-of-scope is important. While I personally find the ideas of profiles and extension systems and a collections spec extremely exciting, they do not exist yet and should not block the clear definition of anatomical orientation. Regarding a prefix mechanism and specifying anatomical orientation in this way, I think further fleshing out is also required. orientation="anatomical:value" does not play nice with the use that I have in mind: I want to be able to parse and work with the values in multiple languages with standard JSON parsers and interfaces, and the colon is not conducive to that. Also, this setup does not appear to work well when there are multiple, exclusive orientations that should be specified.

Furthermore, there are trade-offs in both in generality and specificity and in complexity and simplicity. Generality addresses more use cases, but it is more limited in the information it can convey. Specificity will convey more information, but it will be limited in the use cases it addresses. Nothing real and valuable will be simultaneously completely general and completely specific. And there are similar trade-offs in complexity and simplicity. Where to land should be use-case driven, and I do not think we are too far from hitting the sweet spot for anatomical orientation in RFC 4.

In #267, I expanded the orientation values as suggested by @lassoan. This aligns well with DICOM and the categorization and overview in https://en.wikipedia.org/wiki/Anatomical_terms_of_location. I also improved the description as suggested by @muratmaga to identify dorsal-to-ventral from top/upper (dorsal) to belly/lower (ventral). This is also consistent with the Wikipedia article. The Wikipedia article suggests the use of back, which in this context is used as a counter to front instead of an anatomical location regarding the spine, but I did not use it with dorsal as suggested for clarity.

I think it is important to include the brief but expanded descriptions because we want this functionality to be accessible to more than expert anatomists.

If folks know of additional anatomists that can provide reviews, their feedback would also strengthen the standard.

This is issue thread is meandering and difficult to follow, and I do agree that it should be closed.

[thewtex]

E.g., scientists who study fruit flies and need to assign anatomical semantics to directions in their images would be recommended to handle that with something like a separate insectAnatomicalOrientation key in the axes metadata

Also are there any fish experts here to comment on the anatomical orientations discussed? Much like insects, they are neither bipeds nor quadrupeds.

From what I can find, the values in RFC 4 also cover fish and insects.

[lassoan]

Thank you for the summary @thewtex. I fully agree.

[joshmoore]

Thanks all! Merging the changes in #267 now and closing this issue. Further comments and updates are of course still welcome.