Skip to content

feature/dimension-properties#52

Merged
BrianWhitneyAI merged 5 commits intomainfrom
feature/dimension-properties
Dec 4, 2025
Merged

feature/dimension-properties#52
BrianWhitneyAI merged 5 commits intomainfrom
feature/dimension-properties

Conversation

@BrianWhitneyAI
Copy link
Contributor

Description

The purpose of this PR is to start to resolve #bioio-devs/bioio#25 It adds a new property dimension_properties which allows subsequent readers to attach type and units to dimension metadata. The idea was to keep Scale and PhysicalPixelSize intact and allow for a new property to provide more comprehensive (yet harder to access) information. At a default level the dimesion_properties will only contain the information already found in scale.


value: Optional[float]
type: Optional[str]
unit: Optional[str]
Copy link
Contributor

Choose a reason for hiding this comment

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

I have a few questions about the value, type, unit design here.

  1. can we put some actual typing on unit? (check with what OME advocates, or pick a well used python units library). Or do we want to just allow any old unit whatsoever?
  2. If we have typed units, then I would think about whether you might want to distinguish "unitless" (like for channels) vs None? Could there be a warning for when a reader finds an unexpected/unrecognized unit?)
  3. can we put some typing on type? For this it seems that the OME dimension types are what is expected here.
  4. value is not explained very well in the docstring. What is the value of a DimensionProperty? Is it the scaling from the multiscale transform? In other words, is it the number of unit units in one pixel of this dimension? If so, then it changes depending on what multiresolution level is selected and we might want to note that in a comment too. Kinda wondering if there's a better word than value. Thinking out loud: unit_scale perhaps?

@BrianWhitneyAI
Copy link
Contributor Author

DimensionProperties now only includes type and units. We now enforce the typing of units to pint.Units and match the output against the ome_types registry. Additionally subsequent readers are responsible for assigning unitless and raising warnings about strange values for 'type'.

"ome-types[pint]>=0.2",
"pint", # for typing units
"xarray>=2022.6.0",

Copy link
Contributor

Choose a reason for hiding this comment

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

(nit) blank line

Copy link
Contributor

@toloudis toloudis left a comment

Choose a reason for hiding this comment

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

cool!


@property
@abstractmethod
def dimension_properties(self) -> DimensionProperties:
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't love "properties" in the names here, but the only things I can think of that make it better are words like "metadata" or "info" which aren't a huge step up. Maybe dimension_info is a little better than dimension_properties? idk...

"numpy>=1.21.0",
"ome-types>=0.2",
"ome-types[pint]>=0.2",
"pint", # for typing units
Copy link
Contributor

Choose a reason for hiding this comment

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

🎉

@BrianWhitneyAI BrianWhitneyAI merged commit 9f5e15c into main Dec 4, 2025
16 checks passed
@BrianWhitneyAI BrianWhitneyAI deleted the feature/dimension-properties branch December 4, 2025 21:34
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