New table type PointsTable

[imagejan]

How about defining a new table type PointsTable for point data? I know I can implement this myself elsewhere by extending AbstractBaseTable, but I wanted to ask if this is in scope for ngio to work on a community consensus?
(Eventually, this should go into some spec/extension of the NGFF spec, of course)

Rationale

Tables with type PointsTable included in an OME-Zarr could be recognized by readers (like napari's OME-Zarr-aware plugins) and handled correctly, e.g. by opening a new Points layer in napari.

Context

napari currently auto-detects point data (and shapes data) from CSV files based on this logic:

def _guess_layer_type_from_column_names(
    column_names: list[str],
) -> str | None:
    """Guess layer type based on column names from a csv file.

    Parameters
    ----------
    column_names : list of str
        List of the column names from the csv.

    Returns
    -------
    str or None
        Layer type if recognized, otherwise None.
    """


    if {'index', 'shape-type', 'vertex-index', 'axis-0', 'axis-1'}.issubset(
        column_names
    ):
        return 'shapes'
    if {'axis-0', 'axis-1'}.issubset(column_names):
        return 'points'
    return None

[lorenzocerrone]

Hey @imagejan, that's a cool idea! I can totally see the rationale.

If the scope is simply serializing and deserializing a napari layer, and the rest of the ngio APIs are agnostic to this table type, this should be relatively easy. We could start with a private implementation and then move it to ngio-tables once we're happy with it.

The question about community consensus is quite hard to answer, since it will depend a lot on how the NGFF spec discussion goes. Our long-term goal for ngio-tables is for it to become a fully fledged community-based extension for tabular data.

[imagejan]

I drafted a minimal prototype implementation here:
https://github.com/fmi-faim/ngio-points-table/blob/1229086bf0b659b3441ea865ad5b1cbc830ee5e3/src/ngio_points_table/points_table.py

For this PointsTable to be useful, it would require support in any of the readers, such as the napari-ome-zarr-navigator or napari-ome-zarr plugins, such that points data contained in an OME-Zarr dataset are automatically opened e.g. in napari alongside the image data.

Edit:
I also pushed a small test exercising table IO via ngio, and noticed that with backends like anndata or csv I get dtype mismatches either for index (string vs int) or for the other columns (int64 vs float64). If you have ideas how to mitigate this, I'm all ears. See:

https://github.com/fmi-faim/ngio-points-table/blob/5a4bf71c19e65f576bf24ef333f7a94e2ac0a7ae/tests/test_points_table_ngio.py#L31