Future Coordinate Systems

This page describes a feature planned for a future version.

This page is a work in progress.

Defining a coordinate system for data facilitates display of useful physical information about the data and also facilitates conversion between coordinates within the coordinate system and indexes into the data.

As an example, an interval graphic may be specified to be positioned at 284eV to 294eV. To convert this to an index into 1D data requires a coordinate system describing the conversion from data indexes to eV.

Coordinates

Data arrays might define several coordinate systems, including fractional, data indexed, and zero or more physical coordinate system axes with a dimension type (length, time, angle) for each axis.

Fractional coordinates are independent of dimension size. Data index coordinates are indexes into the data. And calibrated coordinates are typically physical coordinates, often represented by a scale and offset applied to index coordinates.

The calibration for a particular coordinate describes a mapping between a data index and a coordinate value. They are typically comprised of an offset, scale, and units and transform values according to x' = x * scale + offset. Future capabilities may include specifying coordinates as an array and coordinates with non-numeric values, i.e. timestamp.

Within a data item, which might be composed of multiple data arrays arranged into a table or other structure, coordinates might be shared. This facilitates an acquisition set sharing a scan, for example.

Applications may not know all coordinates ahead of time; so adding adding / removing coordinates should be possible.

Processing that produces new data items can create a copy of the coordinates from the source(s) and are not shared. Changing the source coordinates will trigger a recompute which will update the copy. Processing that requires calibrated coordinates to match can check if coordinates are equivalent.

Applications need to have a variety of mechanisms for specifying coordinates and storing them persistently. In some cases, an application requires a physical coordinate, such as 0eV for a channel graphic highlighting the zero loss peak. In other cases, an application requires a data index coordinate, such as this pixel on this detector is non-responsive. And in other cases, an application requires a fractional coordinate, such as this area represents 25% of an image.

Shapes, such as points, rotatable rectangles, rotatable ellipses, lines, channels, intervals, and various Fourier masks, utilize coordinates. Masks (data arrays suitable for masking) can be generated from shapes.

Shapes may have multiple natural representations: a rectangle could be specified as a reference point, size, and rotation; or as top-left and bottom-right with implied zero rotation. A line could be a start and end point; or a start point, length, and angle.

Graphics may also utilize coordinates but have a wider requirement to also specify coordinates relative to the view, panel, or window.

Regions of interest, such as a pick region or a display slice, may utilize coordinates.

For calibrated coordinates, there is a distinction between absolute values and delta values. Shapes, masks, graphics, and regions of interest may need to store either. A rectangle may have center (absolute) and a size (delta).

Inspectors may distinguish between an internal coordinate and a display value. For example, an inspector may show fractional coordinates with a top-left or a center origin. Also an inspector may show a graphic stored with calibrated coordinates in different calibrated coordinates or index or fractional coordinates. When editing, the inspector will need to have a mechanism to decide what coordinate system the user is entering values for.

Various UI elements may give an option to snap coordinates to integer/pixel/channel boundaries. There does not need to be a special mechanism to store coordinates that have been snapped to integer values as long as coordinates are translated to integers using round when utilized.

Questions

• Fractional coordinates are useful for graphics, but are they useful for data?
• Can there be a policy that all coordinates in nion.data.Core are indexed?
• How are shared axes shared in the code and storage? A uuid? An identifier?
• Can common routines in nion.data.Core be implemented to handle transformations on lists of coordinates?
• How to specify that sets of coordinates are related? i.e. defines a distance function and is rotatable.
• Do shapes, if introduced to niondata, need to handle anything other than indexed coordinates?
• Some coordinates (time, angle) may use another parameter (pixel time, camera length); where should it go?
• Some coordinates may be relative to another coordinate (scan, sub-scan); how should this be specified?
• How to handle coordinates that are slightly different? i.e. two scans with a slight drift between them?
• How to handle corrected coordinates? i.e. adjust for energy drift in an SI?

References

Pint: makes units easy

xarray: N-D labeled arrays and datasets in Python