Link Data table, source/target spot are flipped #217
Labels
Comments
|
Resolved via #257 |
tinevez
added a commit
that referenced
this issue
Sep 8, 2023
when creating the table header and collecting values. This is to protect against a bug that appear with features that are not careful to always return the same set of projections when the projections() method is called. This happend for the link target feature and generated the bug below: #217 One can fix the bug by imposing the same order on features, but it is also a plus to make the table rendering independent of this order being preserved.
tinevez
added a commit
that referenced
this issue
Oct 22, 2023
when creating the table header and collecting values. This is to protect against a bug that appear with features that are not careful to always return the same set of projections when the projections() method is called. This happend for the link target feature and generated the bug below: #217 One can fix the bug by imposing the same order on features, but it is also a plus to make the table rendering independent of this order being preserved.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Dear mastodon stuff,
recently I observed that target and source spot ids appear in flipped order in the Link Data table. Surprisingly, this seems to occur randomly but I can reach the expected order (source, timepoint n -> target, timepoint n+1) when I repeatedly run "compute features".
My input data are a bunch of 3D image stacks from a dozen timepoints, but I guess this does not really matter. Could you have a look into this?
Many thanks
Christian
The text was updated successfully, but these errors were encountered: