Allow Parsing NML Nodes Without Radius Attribute

[fm3]

URL of deployed dev instance (used for testing):

• https://nmlparserdefaultradius.webknossos.xyz

Steps to test:

• via dashboard, upload an NML file with nodes that do not have radius attribute
• should not be rejected, nodes should get default radius

Issues:

• fixes Allow to upload NMLs with nodes without radius attribute in backend NML parser #4953

---

• Updated (unreleased) changelog
• Ready for review

[fm3]

@daniel-wer you mentioned in #4953 that the default radius should be 30, as that value is used in the front-end parser. Do you remember how this value was decided upon?
There is another point in the back-end code with a default node radius of 120. This is used when creating plain skeleton tasks with a start position. An initial node (with radius 120) is placed at the start position there.
I do not know how the radius of user-set nodes is set either. Maybe this difference is fine and by design, I just wanted to double-check that with you :)

[daniel-wer]

@fm3 Very good that you're paying attention here! I had a look and there actually seems to be a lot of confusion around this value as well as two different defaults in the frontend (plus the also different default in the backend) 🙈

When uploading NMLs with nodes without a radius attribute, the default radius is 30. I cannot reconstruct how I chose this value, but it seems that I chose it somewhat randomly, because at the time I overlooked that the node radius is in nm and not in pixels (only visible if "Overrride Node Radius" is deactivated), so it heavily depends on the current zoom value, how large nodes appear. To complicate the matter, a certain minimum node size is assured by the shader to avoid tiny nodes.

When creating the first node in a tracing, the radius is set to be 10 * getBaseVoxel(state.dataset.dataSource.scale), so 10 voxels. This also seems rather wrong to me. Why should the default size of a node be 10 voxels instead of 1 (or 0.5 actually, but see my next point). I also noticed that the radius is mistakenly used as a diameter in the shader.

When creating other nodes, the radius of the currently active node is copied.

Practically speaking, I don't think this matters a lot, because most users have the "Overrride Node Radius" setting activated, but I would still like to unify and fix this. My intuition would be, for a dataset with scale 10x10x30 nm³, to set the default node radius to 5 nm, so that the node is 1vx in diameter in the dimension with the highest resolution. Happy to jump on a call about this and to contribute frontend fixes to this PR.

[fm3]

@daniel-wer as discussed I changed the default radius (both in the NML parser and in the Task initial node) to 1.0f. If you are certain that this change won’t cause problems, feel free to add the front-end part here.

[daniel-wer]

To complicate the matter, a certain minimum node size is assured by the shader to avoid tiny nodes.

To extend this point, the minimum node size assured by the shader is the "(Min.) ParticleSize" setting above the "Override Node Radius" setting. Most (if not all) users will have set this setting to a reasonable value and will likely have activated "Override Node Radius" as well (the minimum particle size is applied regardless). The unification of the default node radius in this PR shouldn't cause any problems, therefore.

[youri-k]

Backend LGTM apart from the changelog 🎉

[daniel-wer]

@philippotto Could you have a quick look at the frontend code (see our discussion for why we think it's fine to unify and change the defaults) and approve if you agree and the code LGTY? :)

[philippotto]

Great to see this clean up :)