[cmalinmayor]

After much waffling about whether or not to scale position attributes, this is my current proposal. I branched off #262, which keeps the "default" as pixel units, as opposed to the current main default of "world".

[codecov]

Codecov Report

❌ Patch coverage is 98.46154% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.53%. Comparing base (b6b76ca) to head (a4937ac).

Files with missing lines	Patch %	Lines
src/funtracks/import_export/_tracks_builder.py	83.33%	1 Missing ⚠️
src/funtracks/import_export/csv/_import.py	94.73%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #307      +/-   ##
==========================================
+ Coverage   94.36%   94.53%   +0.17%     
==========================================
  Files          64       64              
  Lines        3883     3988     +105     
==========================================
+ Hits         3664     3770     +106     
+ Misses        219      218       -1     

☔ 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.

[TeunHuijben]

Hi Caroline,
Claudio and I reviewed the PR and found a few places where world/pixel was still confusiong/wrong, so I took the liberty to commit the changes directly to this PR. A summary of what we changed:

1. GEFF round-trip of world-unit tracks. They came back as position_units="pixel" because nothing in the file marked them as world. The export now writes position_units into the funtracks extra metadata, and import trusts it.
2. CSV export in world mode. It wrote world coordinates next to the *_scale columns, so a reader scaled them twice. The export now divides by the scale, so coordinates are always pixel, as the docstring says.
3. CSV import. The z_scale/y_scale/x_scale columns were imported as node features and the scale was lost. They're now read as tracks.scale (an explicit scale= still wins), and CSVTracksBuilder overrides _resolve_import_scale for this.
4. Segmentation check on import. validate_graph_seg_match treated world positions as pixel indices, so valid files failed. It takes an optional scale again, passed only when position_units == "world".
5. GEFF unit detection:
   • GEFFs from v2.2.0 (version stamp, no position_units) are now read as world. Before, they were guessed as pixel and scaled twice.
   • The axes-scale check now compares against the user's scale if given, not only the scale in the file metadata.
   • It uses np.allclose instead of ==.
6. Small cleanups. I fixed the _resolve_import_scale comment in build(), renamed pixel to centroid in _centroid(), and fixed a couple of typos in comments and docstrings.

Three things are still open/concerns:

• External CSV: When importing an existing CSV, nothing tells us whether the coordinates are in pixel/world units. How do we solve this? Should we add a UI element that alows the user to set it?
• Breaking API changes: nodes_from_points_list lost its scale argument, compute_graph_from_points_list changed what its scale means, and positions now default to pixel. These need a changelog note and updates in motile_tracker.
• update_scale: it skips the undo history, which the docstring should probably mention.