Transforming fields in a table

[tischi]

We have code like this to retrieve an numeric feature in a table:

    public Double getNumber( String feature )
    {
        return tableSupplier.get().row( rowIndex ).getNumber( feature );
    }

Now, if this table has been transformed, probably we would like to transform whatever this function returns, is applicable? For example, if this contains the position of a spot?

Note, that there are dedicated methods to return the position:

    public double[] positionAsDoubleArray()
    {
        return position; // this would be transformed.
    }

Those methods are aware of the transformation, so this is not an issue.

See here: https://github.com/mobie/mobie-viewer-fiji/blob/1f9ecbaf439695c4ebe0a352b1424bac76bf56f6/src/main/java/org/embl/mobie/viewer/table/saw/TableSawAnnotatedSegment.java#L172

Not sure what do to...we would need a mechanism to know which columns should be transformed and how.

[constantinpape]

I think for the time being we should just transform the default columns that we know are spatial (segmentation: anchor, bb, spots: coordinates). I agree that it would eventually be nice to also support transforming other columns. I am not sure what the best option for this would be. One option would be to have an additional field in the spec like spatialColumnNames or so and it to the relevant source specs. (But this is not a perfect solution for newly loaded tables, so maybe we can come up with better alternatives.)

[tischi]

This is maybe not so simple (at least on my side).

Example: Grid view: the coordinates must be transformed such that the segments are at the correct position in the global grid coordinate system. However, those transformations are biophysically meaningless. Thus transforming the spatial values in the table, in the grid view, makes not make much sense?!

I feel this may be an issue with the current overall design. There are bio-physically meaningful transformations and there are the grid views. Currently we handle both with the same machinery.

For now, I suggest not to transform the table values and revisit this once we have a use case (e.g. something where we do a registration in MoBIE involving of a label mask image).

[constantinpape]

I agree. Let's postpone this until a use-case arises.