Standardizing coordinate values

[simleo]

For the background, see CellMigStandOrg/CMSO-samples#18.

It appears that while some tracking software packages report X, Y coordinates in pixel units, others use different units (such as physical size). While in the former case mapping objects back to the image is straigthforward, in the latter we currently have no way of providing information on which transformation is required to convert to pixel-based values. We should either:

• Deal with this during data package generation, ensuring that the coordinates that end up in the objects file are in pixels
• Add a field somewhere that specifies the required transformation. This might be relatively straightforward in the case of a simple scaling factor (e.g., a single float value) but trickier in more complex cases (assuming they occur in practice)
• Note that, in the case shown in BaF3: add TrackMate data CMSO-samples#18, the scaling factor was actually retrievable from the metadata. In this case, the data package should minimally have an option that basically says "coordinates are in physical size", so that the reader knows what to look for.

[pcmasuzzo]

It seems reasonable to me to have this information stored at the moment of the data_package generation, perhaps best in the json file that accompanies the csv files.

Would it even make sense perhaps to have an extra resource in the ini file that says:

unit_coord = something either pixel/physical size/whatever ?

[simleo]

Discussed at the CMSO meeting in Essen. Physical pixel size has been changed to required (i.e., one of the minimal requirements), since it's needed for several cell migration related measurements. Since coordinates in pixels are also needed for other measurement types, one should be able to get both. From a data economy perspective, in the objects file we should keep coordinates in either pixels or physical unit and store the pixel size somewhere else (json file?).

[simleo]

Discussed at the July 13 call. Among the current formats, only TrackMate supplies this information, but there seems to be no specific encoding. The relevant XML element is:

<Model spatialunits="foo" timeunits="bar">

Where "foo" and "bar" might come from the image metadata via Bio-Formats if available, but can also be overridden by the user via an input box. Due to this, for now we agreed on adding support for a spatial and a time unit, but only as free text strings.

[simleo]

Fixed in #47.