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.