Fix frame buffer bug where predecessors were not checked properly

[cmalinmayor]

Proposed Change

@bentaculum I also saw issues with the frame buffer not updating when I expected it to. Upon closer inspection, there was a bug in how we were checking the successors. This PR fixes that bug. Sorry!

Previous discussion of possible frame buffer issue #100 (comment)

Types of Changes

What types of changes does your code introduce? Put an x in the boxes that apply.

• Bugfix (non-breaking change which fixes an issue)
• New feature or enhancement
• Documentation update
• Tests and benchmarks
• Maintenance (e.g. dependencies, CI, releases, etc.)

Which topics does your change affect? Put an x in the boxes that apply.

• Loaders
• Matchers
• Track Errors
• Metrics
• Core functionality (e.g. TrackingGraph, run_metrics, cli, etc.)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the developer/contributing docs.
• I have added tests that prove that my feature works in various situations or tests the bugfix (if appropriate).
• I have checked that I maintained or improved code coverage.
• I have checked the benchmarking action to verify that my changes did not adversely affect performance.
• I have written docstrings and checked that they render correctly in the Read The Docs build (created after the PR is opened).
• I have updated the general documentation including Metric descriptions and example notebooks if necessary.

[msschwartz21]

I'm going to go in and fix the test case for this so that the tests would have actually caught this bug...

[bentaculum]

Nice catch! Can we generally describe the influence of this fix on the division metrics calculated up to this point? Are old metrics too optimistic/pessimistic?

[cmalinmayor]

@bentaculum The old version incorrectly penalized some (most?) correct divisions when frame_buffer > 0. Specifically, it checked if the successors had the same ID, not if the successors were matched, so if your prediction and candidate nodes had different IDs, it would never count an offset division as correct. For linking only experiments with GT detections, it probably won't change anything, but for experiments with predicted detections, performance should improve for division metrics when frame buffer > 0.

[DragaDoncila]

@cmalinmayor @msschwartz21 took a look at this PR and if I'm understanding correctly, the bug was that when checking successors, we were directly using the graph node IDs rather than converting them via the mapper. And the test was passing because our division_graphs are using identical node IDs right? So if we just tweak the get_division_graphs util to use different node IDs that should be a sufficient test that fails on main and passes with this PR?

[msschwartz21]

@DragaDoncila that's correct! I'll fix the test case in the next week or so. It's an easy fix but life has been busy 😂

[DragaDoncila]

@msschwartz21 no rush at all, just making sure I understand the change!

[DragaDoncila]

Looks good to me! Thanks for editing the tests @msschwartz21