GUI: Tracing improvements

[tferr]

Inconsistencies/Improvements in the UI, as reported by @carshadi:

• Could be useful if the just finished path becomes the selected one e1ad0c3
• A way to re-initialize a "finished" path for additional A* tracing would be helpful 091c566
• There should be a way to select the children a selected path 5a841e5
• "Activate canvas on mouse hover" should be active by default
• In order to make a fork point, you need to hold down ctrl+shift and then move the cursor slightly before "Fork Point" appears b91cecb 49c3fb1
• Deleting a path from the path manager, while still in edit path mode, the delete does not occur until switching back to tracing mode (it occurs in the path manager but the canvas does not update until switching) ead9dc7

[tferr]

@carshadi, thanks for the feedback! These changes were pushed this morning to the Fiji updater. Can you please check everything works as expected?

[carshadi]

1) finished path becomes selected path - works as expected. 2) ability to extend "finished" paths, works as expected. 3) selecting/deleting all children of a parent path - works as expected. 4) activate canvas on mouse hover by default - not yet addressed but not essential 5) alt + shift to create a fork point without extraneous cursor movement - the appended path is disconnected, forming a separate path instead of a branch. The cursor snaps to where the fork point should be placed, but the node is added to where the cursor is, which may not be the snapped location. 6) delete selected path while editing that path, edit mode is exited and path is deleted - works as expected.

All issues except the 5th have been resolved

[tferr]

alt + shift to create a fork point without extraneous cursor movement - the appended path is disconnected, forming a separate path instead of a branch. The cursor snaps to where the fork point should be placed, but the node is added to where the cursor is, which may not be the snapped location.

Bummer, somehow had missed it. This morning release should finally fix it with 49c3fb1. Let me know if it doesn't. I did notice a weird thing with forking: if you use a display canvas (an empty placeholder image) and try to fork, the forking point is way off. That could be a bug: Perhaps the snap-to-signal cursor remains active, but goes awry because there is no signal?

I will look at the "activate canvas" next

[carshadi]

alt+shift now works as expected!

[carshadi]

Is there supposed to be a blank canvas when starting SNT without an image? Because on my machine (Windows 10 64 bit) only the control panel, path manager, and console open. Don't see any empty image canvas.

[carshadi]

The placeholder canvas does appear when importing an swc though

[tferr]

The edit commands in the contextual menu require an image to be displayed. I decided to always have them available when analyzing a complete reconstruction, which may happen in the absence of the traced imagery (e.g., a cell downloaded from an online database), hence the usage of a "display canvas". At startup, SNT will create an empty placeholder image from the computed bounding box of the reconstruction file. If no reconstruction is provided, SNT is not aware of any bounding box and does not create a placeholder image. (To be more exact: SNT always requires an image to be present, it is just in this latter case it creates a 1x1x1 voxel image that remains hidden from the user).

The options in the initial prompt are really just a convenience. One can go ahead and specify neither an image nor a reconstruction file and perform those steps at a later point from SNT's File menu. But the initial prompt is somewhat smarter: it adjusts options depending on inputs, which saves time and clicks: E.g., if you save a reconstruction file named after the image and place it in the same directory, it will pick it up.

Here is an example in more detail: I have the OP_1 image in a directory with a bunch of reconstruction files. If I run SNT and choose _OP1.tif it automatically chooses _OP1.traces. In debug mode, the Console logs what is happening in the background: SNT is retrieving a file list, and computing Levenshtein distances for the filenames, keeping track of the "closest" reconstruction file:

[INFO] [SNT] Finding closest pair for /home/tferr/code/OP_1/OP_1.tif
[INFO] [SNT] Found 4 traces files
[INFO] [SNT] Levenshtein cost for 'OP_1-soma-test.traces': 10
[INFO] [SNT] Levenshtein cost for 'OP_1-uncompressed.traces': 13
[INFO] [SNT] Levenshtein cost for 'OP_1.traces': 0
[INFO] [SNT] Levenshtein cost for 'OP_12.traces': 1
[INFO] [SNT] Identified pair 'OP_1.traces'

Should this be better documented?

[carshadi]

makes perfect sense, will mention it in the screencast