[Follow up]: Multiple segmentation layers

[philippotto]

Follow up for https://github.com/scalableminds/webknossos/pull/5683.

Bugs & Weirdness:

• [x] Toggling of segmentation layer via "3" does not work properly when there are multiple segmentation layers
  • how should we remember which layer was active before?
• [ ] "Create tracing" when viewing DS, simply picks visible segmentation layer as a base
  • [ ] also provide dropdown / modal as in dashboard to configure how the annotation looks
    • maybe default to new layer? <-- should be carefully considered
• [x] Make hybrid simply picks visible segmentation layer as a fallback
• [ ] segmentationPatternOpacity is shared across all segmentation layers
• [ ] When having multiple segmentation layers and mesh files, the UI is a bit weird. For example, switching to another seg layer will hide loaded meshes in the meshes-tab, but they will still be visible in the 3D viewport.
• [x] Enabling merger mode in a skeleton-only annotation when multiple segmentation layers exist and then switching between these layers will result in weird behavior, as the merger mode refers to the currently visible layer (done in #5771; the merger mode remembers for which layer it was activated)

Refactoring:

• [x] group currentMeshFileByLayer, availableMeshFilesByLayer, isosurfacesByLayer together in store
• [x] mapping setup is complicated, since we only support one mapping at a time. getSegmentationLayerWithMappingSupport is used to listen on the layer for which the mapping should be bound on the GPU, but that function is messy, since it has to guess which layer is about to get used for a mapping. Currently, we cannot use isMappingEnabled since that is set to true at the very last stage of the mapping activation. We probably need another state (isBeingActivated) or something similar to avoid the guessing part. After refactoring test the following: open a dataset with two segmentation layers (both should have JSON mappings) and enable one mapping. Without the guessing logic, this simple step doesn't work right now.

More Features:

• [x] #5759
• [ ] #5760
• [x] #5910
• [x] #6143
• [x] #5855
• [x] #5802
  • [x] then, remove the "unlinkFallbackSegmentation" feature
• [ ] Allow to import volume tracing into new annotation layer
• [ ] Always default to "non volume annotation" layer when creating an annotation. Instead, the user should be able to easily edit an existing segmentation layer ad-hoc (there could be an edit button for the layer). Note the following details:
  • [ ] the volume annotation tools should be shown even though no volume layer exists yet. clicking on them could ask the user which layer should be created.
  • [ ] adding a volume layer should not require a reload
• [ ] If multiple segmentation layers can be rendered, ensure that only one mapping can be enabled in the UI right now (as mapping needs 3 textures we don't want to do this n>1 times).
  • this is a bit tricky because isEnabled in store is decoupled from the UI button. We need to ensure that getSegmentationLayerWithMappingSupport already returns the correct value quite early (~maybe this is easier once https://github.com/scalableminds/webknossos/pull/5738 is merged~ <-- it's still a bit tricky)

[normanrz]

"Create tracing" when viewing DS, simply picks visible segmentation layer as a base

• [ ] also provide dropdown / modal as in dashboard to configure how the annotation looks maybe default to new layer? <-- should be carefully considered

I think there should be one volume annotation layer per segmentation layer, so that each segmentation layer is editable.

[philippotto]

I think there should be one volume annotation layer per segmentation layer, so that each segmentation layer is editable.

I'd rather converge on a lazy-create approach, since the existence of a volume + fallback layer means that twice as many buckets are requested for that layer when viewing it. If the ad-hoc "add volume layer" functionality is smooth (i.e., does not require a reload), both approaches should/could feel very similar for the user.

[normanrz]

I think there should be one volume annotation layer per segmentation layer, so that each segmentation layer is editable.

I'd rather converge on a lazy-create approach, since the existence of a volume + fallback layer means that twice as many buckets are requested for that layer when viewing it. If the ad-hoc "add volume layer" functionality is smooth (i.e., does not require a reload), both approaches should/could feel very similar for the user.

Alternatively, we could create zero volume annotations and add an "edit" button to segmentation layers within an annotation.

[philippotto]

Yes, this sounds like a good idea. However, it's a bit more work (e.g., brush tools should be shown even though no volume layer exists yet; adding a layer should not require a reload etc.). I'll integrate this in the issue description, but I'd still solve the low hanging fruit first by adding a dropdown to the the "Create Annotation" button.