I’ve got an information from one of the researchers, that we shouldn’t split large cells to smaller branches, especially, if a cell has already been marked as completed.
The reason is, that the researchers use a tool, that finds latest id for a given segment (which makes sense, because they want the latest version of a cell) and if we’ve splitted a cell, they’ll get only that small fragment, that contains the given segment.
If there’s no other possiblity, the proposed way is to cut a single branch, fix all the issues and merge it back ASAP.
If a cell isn’t completed, the problem probably isn’t that important.
3 Likes
Thank you KK for posting this! We are all figuring how to manage the new open-source aspect of FlyWire and appreciate you learning aside us as we refine these processes.
I’ll make sure to mention this in future streams and demos too.
2 Likes
My own suggestion is that, after you’ve cut, fixed and merged back a branch, mark the cut/merge point with a large ellipsoid annotation, so you’ll know, on which branches you’ve already worked.
Also, when you’ve split a branch, but didn’t finish fixing it and planning a longer break, merge it back and maybe mark that temporary merge with a bounding box annotation. That way the cell will be whole for the most time.
1 Like
Thanks for the heads up on this. I actually have started to use a similar work flow on larger cells but it’s good to know exactly what is requested from the scientists on the project.
For an example of what KK’s mentioning I’m currently doing similar in this large cell:
https://ngl.flywire.ai/?json_url=https://globalv1.flywire-daf.com/nglstate/5072733851353088
Edit: A second link to show an ‘in progress’ branch state -
- Each branch I’ve gone to work on so far, I’ve marked with a ‘branch point’ in a separate annotation group wherever the branch connects (or where I’m splitting it off).
- Once split, I hide the main cell as it causes added load times and for visual clarity to focus on my segmented branch.
- I use a separate annotation group/tab for the branch I’m working on as I keep track of points I’ve checked (this one in particular since it turns on itself a lot).
- When I’m done with that branch, I merge it back to the whole.
I aim to work on one branch at a time/session (in this large DM’s case), so that I’m not holding up the entire cell. With KK’s tip though I will make sure that if I ‘leave off,’ I will merge back to the main cell.
I do think that this points to the possible need for better logs/annotations on segments, or rather some sort of ‘permanent note’/‘working note’ that anyone can access. I’m not bothered by having private annotations, but I think it’d be useful to add a note from time to time on certain issues or large work projects (even if they are also temporary notes, like “Working on branch, point x” “Branch done and merged”).
3 Likes
sounds like a option to uncomplete a large cell if you need too work on in might be a option if it is a big problem
2 Likes
Another thought, though I don’t know the programming that would be involved for this:
Allow editors to create “ghost” segments.
“Ghost” segments would be essentially new, duplicate segments created from a multi-cut as if it was actually split, while the previous segment remained untouched. Editors could then view/work on the ghost segment, and then choose to discard the segment (for instance, if used primarily to see what a split would affect, ie no changes were made) or merge and match the segment to the existing cell structure - at which point the ghost segment would replace the existing segment entirely, transferring any edits to the complete branch.
I suppose the actual technical process (on the coding side) would be something like:
- Save the user created multicut data
- Create in a temporary dataset (ghost) the segments created by the multicut, opened in a new view/window?
- On ‘Discard,’ delete temporary (ghost) segments
- On ‘Replace,’ excute the saved multicut on the live cell, transfer the ghost segment data to the live data and display the new segments to user. (Probably both old and new segments here, to allow users to compare and discard the old segments themselves before merging).
I could see this being a useful tool for scientists in viewing data too, for instance if they wanted to view a part of the cell in isolation.
I was actually thinking about this. It might be to difficult to do via an addon. It would probably required a server, which would host the “ghosts” and remesh them after each split or merge.
If it was done on the Production server, it would probably lead to issues, like the one with your @AzureJay and @bl4ckscor3 cells, which are merged together and some fragments belong to two different segments (the glia merger and a cell).
But I’ll definitely play with the idea, because it might be useful for a before and after comparisons (like, what was at the beginning and what you’ve changed in a cell) or even some sort of custom highlight.
1 Like
I was actually wondering if it could be done by loading segments in Sandbox, or if there’s no direct connectivity between the two.
If you can make it as an addon that’d be great, but I’d like to see it as a permanent feature one day!
It would probably be possible to use both Sandbox and Production at the same time (not sure though).
Agree, it would be great, if done officially with some official tools to work with it.
1 Like