[WIP] allow custom colors for volume annotation segments

[fm3]

URL of deployed dev instance (used for testing):

• https://___.webknossos.xyz

Steps to test:

• abc

Issues:

• fixes #6306

---

(Please delete unneeded items, merge only when none are left open)

• [ ] Updated (unreleased) changelog
• [ ] Updated (unreleased) migration guide if applicable
• [ ] Updated documentation if applicable
• [ ] Adapted wk-connect if datastore API changes
• [ ] Adapted wk-libs python client if relevant API parts change
• [ ] Needs datastore update after deployment
• [ ] Ready for review

[philippotto]

@fm3 I think the backend cannot accept update actions where a segment color is set to null. I want to support this to reset a color to its original default. After saving the backend returns the old color value for the segments. Could you have a look? If you want to reproduce it, you can use this branch: https://github.com/scalableminds/webknossos/pull/6417.

[fm3]

Sure, I changed the UpdateSegmentVolumeAction accordingly :) Note that in the UpdateTreeSkeletonAction the old logic is still in place (if no color is in the update action, don’t change it). However, I don’t know if the front-end even sends such actions for skeleton trees.

[philippotto]

Thank you!

However, I don’t know if the front-end even sends such actions for skeleton trees.

If I see it correctly, the front-end always sends all properties when updating entities via the update actions. Theoretically, we could make this "sparse" so that things which shouldn't be changed are not sent, but let's not get into that now.

Note that in the UpdateTreeSkeletonAction the old logic is still in place (if no color is in the update action, don’t change it)

The front-end will always send a color property (it's simply set to null in the unset case). Since we don't employ the sparse update logic, it doesn't really matter, but maybe it's easy to set the right "precedent" in the implementation (i.e., if color is null, set it to null; if it's not set, don't change it). However, it should work as is now, too :)

[fm3]

Ah sorry, I talked both about null/none and about absent. Those are not distinguishable in the backend. So if it is null, it is also not changed (for skeleton trees)

[philippotto]

Those are not distinguishable in the backend.

Oh, then there are not many options ^^ The current way sounds good then :+1:

[fm3]

@leowe Could you have a look at the backend diff? I already tested that the NML reading/writing works. The note that front-end implementation is here: #6417

[philippotto]

I merged the front-end PR into this PR now. After the back-end is reviewed, we can do a final testing round, I suppose. @leowe Either skip the frontend files while reviewing or exclude the latest commit from the diff view :)

[fm3]

@philippotto could you resolve the merge conflict and add a changelog entry? Do you know if any docs need updating?

[philippotto]

@philippotto could you resolve the merge conflict and add a changelog entry? Do you know if any docs need updating?

done! I noticed that there were no docs for the segment tab in general which is why I added a small section.

[philippotto]

I skipped the frontend for now. Will test tomorrow.

yeah, the frontend was already reviewed. just a last testing round would be nice :)