Rethink integer-casting of node positions

[philippotto]

Context

Skeleton tracings. Also see (and post update there): https://discuss.webknossos.org/t/internal-node-positions-with-sub-voxel-resolution/1741

Expected Behavior

Floating values for node positions should be correctly stored /edit: or the positions should be immediately rounded after creation/movement of a node.

Current Behavior

Floating values for node positions are cast to integers.

Steps to Reproduce the bug

• [ ] Cannot reproduce the bug anymore / needs deeper investigation.

1. create nodes which are very close to each other in the YZ viewport (zoom in quite a lot)
2. ensure the nodes are in the same z slices, but not on top of each other
3. save & reload --> now all nodes are on the same z

Your Environment for bug

• Browser name and version: e.g. Chrome 39
• Operating System and version: e.g. Windows 10
• Version of WebKnossos (Release or Commit):
• [ ] Specific to long-running jobs (set jobsEnabled=true in application.conf)
• [ ] Specific to webKnossos.org (set isDemoInstance=true in application.conf)

[fm3]

Node positions are stored as three integers in the protobuf definition (see here and here) I’m pretty sure that this was by design at some point. Do you think it must now be considered a bug? This will probably be difficult to change without a full migration on the fossildb-stored protobuf objects and update actions

[philippotto]

Maybe it's alright to store the coordinates as integers, but it can definitely lead to weird behaviors (i.e., save and reload will produce something different). I see three options:

a) Leave it as is (this oddity is only recognizable when zooming very far in which might be an unrealistic use case) b) Round the coordinates during creation/movement of a node. c) Change protobuf to float.

I assume (b) would be the best trade-off between cleanliness and effort. However, (a) is also fine for me, as it's really not a pressing issue..

[fm3]

I agree with your three options.

In order to decide whether a is good enough, I’d like to ask: How are z coordinates handled when creating a node in the XY-Viewport? Is the (float) camera position used or the (int) position shown in the coordinate field?

[philippotto]

How are z coordinates handled when creating a node in the XY-Viewport? Is the (float) camera position used [...]

Yes-ish. The main case is probably creating a node via the mouse and then floating point mouse position is used.

[fm3]

Mouse position is 2d, though, so this does not specify which z coordinate is used, if I click on the XY viewport, I think? I’m asking with https://github.com/scalableminds/webknossos/issues/5653 / https://github.com/scalableminds/webknossos/issues/5233 in mind

[philippotto]

Ah, sorry, I forgot about the 3rd dimension. Yes, for the 3rd dimension, the current camera's float position is used.

[fm3]

Alright, thanks :) I think it would be better to do b then, for the moment, since this change on reload can be confusing/disappointing. b should be fairly easy to implement, I’d hope? If at some point we decide that we need float precision for nodes then c is also an option.

[philippotto]

In context of the proofreading tool, I stumbled about this issue again. The backend expects integer positions there, but if the user created some nodes manually (or god forbid moved them), this assumption is not true anymore. Instead of carefully casting before calling api endpoints, I think that the suggestion from above (round the position directly after creation/mutation) would be a good solution.

[philippotto]

not sure whether this affects https://github.com/scalableminds/webknossos/issues/4366 in some way.