Currently, selecting a Path changes the canvas slice position to the first node on the Path.
This is an ergonomic impediment in almost all typical tracing workflows (that I have tried at least).
Cases 1 and 2 apply primarily to tracing axon, which necessitates a different workflow compared to tracing dendrite.
Case 1: User traces hierarchically, starting with the backbone and adding higher order branches as forks.
Paths are from root -> terminal or branch -> terminal in this case, not branch -> branch
After finishing a Path, you want to be able to create a fork somewhere along that Path, usually towards the middle/end of the segment. However, when the slice position updates where the first node is, you lose your orientation since this is likely outside your field of view. The user then has to scroll all the way back (potentially through hundreds of slices) to where they were, which is both time consuming and taxing on the wrist.
Case 2: User traces hierarchically, but every branch is created as a separate Path
Similar situation to the above, but this time the user will always create forks at the end of the Path, so having the slice jump to the start throws them off
Case 3: Tracing dendrites, user creates a single "soma" point and traces multiple basal dendrites out of that point
This is the only case where I think the original behavior somewhat makes sense, since each basal dendrite is usually traced as an outward connection from the "root" or soma point(s). However, the user still has to trace out higher order branches, which generally takes the bulk of tracing time (for more complex cells at least), going back to cases 1 and 2.
I think we shouldn't change the slice position, so the user always knows where they are in Z and can navigate/place forks quickly.
Currently, selecting a
Path
changes the canvas slice position to the first node on thePath
. This is an ergonomic impediment in almost all typical tracing workflows (that I have tried at least).Cases 1 and 2 apply primarily to tracing axon, which necessitates a different workflow compared to tracing dendrite.
Case 1: User traces hierarchically, starting with the backbone and adding higher order branches as forks. Paths are from
root -> terminal
orbranch -> terminal
in this case, notbranch -> branch
After finishing a Path, you want to be able to create a fork somewhere along that Path, usually towards the middle/end of the segment. However, when the slice position updates where the first node is, you lose your orientation since this is likely outside your field of view. The user then has to scroll all the way back (potentially through hundreds of slices) to where they were, which is both time consuming and taxing on the wrist.
Case 2: User traces hierarchically, but every branch is created as a separate Path
Similar situation to the above, but this time the user will always create forks at the end of the Path, so having the slice jump to the start throws them off
Case 3: Tracing dendrites, user creates a single "soma" point and traces multiple basal dendrites out of that point
This is the only case where I think the original behavior somewhat makes sense, since each basal dendrite is usually traced as an outward connection from the "root" or soma point(s). However, the user still has to trace out higher order branches, which generally takes the bulk of tracing time (for more complex cells at least), going back to cases 1 and 2.
I think we shouldn't change the slice position, so the user always knows where they are in Z and can navigate/place forks quickly.