segmentation_shape metadata reformat

[TeunHuijben]

connected to: funkelab/motile_tracker#459

Problem:

• tracksdata saves segmentation shape in geffmetadata as .extra.tracksdata.shape
• funtracks/motile_tracker save segmentation shape in zarr-metadata as segmentation_shape at the top level (outside the geff metadata)
• in retrospect, the latter is not the smartest design decision, because 1) top-level non-geff metadata doesn't survive round-trips, and 2) it is inconsistent with tracksdata

Solution:
This PR removes the segmentation_shape logic, and fully uses the existing tracksdata format of saving the shape in metadata.extra.tracksdata.shape. When reading the shape from the metadata we do a double check for backwards compatibility.

For geffs that are exported from motile_tracker and then imported, it doesn't matter where we save the shape, because that is an internal discussion. But for geffs exported by other tracksdata-based tracking tools (ultrack, hoct, etc.), we are now natively compatible.

I will implement the accompanying changes in motile_tracker in a separate PR there

[codecov]

Codecov Report

❌ Patch coverage is 93.33333% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.94%. Comparing base (c30396a) to head (18c9c51).
⚠️ Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
src/funtracks/import_export/geff/_import.py	86.66%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #260      +/-   ##
==========================================
+ Coverage   93.92%   93.94%   +0.02%     
==========================================
  Files          59       59              
  Lines        3326     3337      +11     
==========================================
+ Hits         3124     3135      +11     
  Misses        202      202              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cmalinmayor]

Can we add an API in tracksdata for saving and loading segmentation metadata (shape and voxel size?). Then, we don't need to depend on internal tracksdata implementation details, and tracksdata can change where this info is stored at any time.

[TeunHuijben]

Hi @cmalinmayor, good point! I made the following changes:

• tracksdata .to_geff is updated to automatically save the tracksdata metadata within the geff metadata, so we don't need to do that separately anymore
• tracksdata shape api has been changed, so we can now just read/write graph.metadata["shape"], without needing to know how td that exactly saved in the metadata
• a new tracksdata io helper allows reading the segmenation shape from a geff store, before loading the graph. So all of this allows us read/write/see the shape, from a surface level point of view

Some other changes along the way:

• small change to the benchmark to run them on 1 machine, for fair comparison
• some skips in the tests_old, because they were dependend on segmentation_shape not segmentation

[cmalinmayor]

Why skip instead of delete?

[cmalinmayor]

I had claude explain it but I still curious. i think given my backward compat concerns we should just keep them for one more release

[TeunHuijben]

Agreed, I made it a skip

[cmalinmayor]

To ensure no breaking motile_tracker:
Write both keys for one release cycle. On write, set both graph.metadata["shape"] (new,
tracksdata-aligned) and keep _update_metadata(segmentation_shape=...) (old, what
motile_tracker's solve.py/motile_run.py still write and read). This is a superset of what
the PR already does — right now it only reads the old key, it doesn't write it. If you
additionally keep writing the old key for a release or two:

• motile_tracker's main keeps working unmodified against the new funtracks release (its
  writes still land in the old key, its reads still find the old key).
• New tracksdata-based tools get the new key immediately.
• You then update motile_tracker at your own pace (not tied to this PR/release), switching
  it to graph.metadata["shape"], and only after that ships do you drop the old-key write
  from funtracks.

This is the standard "dual-write, single-read-with-fallback, then cleanup" migration —
it's more code churn than a single clean cutover, but it decouples the two repos' release
trains, which is what you're actually trying to buy.

[TeunHuijben]

Hi @cmalinmayor, I agree with your solution, and keep both writes (the old and the new). This also means that all the old tests can stay intact, apart from 1 single change.

[cmalinmayor]

I still have some qualms with the Tracksdata API, but I'll make PRs upstream for that, and stop blocking your progress here.

EDIT: reverting my change because it was incorrect.
🍅 👍 🎉