Conversation
PaulHax
added this pull request to stack #965
September 21, 2026 20:08
✅ Deploy Preview for volview-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
PaulHax
force-pushed
the
segmentation-integration
branch
from
September 21, 2026 21:53
3b0aa90 to
59a436e
Compare
One image-scoped segmentation replaces segment groups. This adds the store that owns mask identity, attachment and lifecycle; labelmap import, restore and interchange; the paint, polygon and process editing paths with their algorithms and workers; the slice representation; manifest 7.0.0 serialization with migration of legacy state; the annotation tools and stores retargeted at segment identity; processing inputs bound directly to segmentations; the flat segment list with sidebar controls, shortcuts and eyedropper; and the unit and end-to-end coverage. It deletes the segment group store, its view config and the old controls. Suggested reading order: src/segmentation/store.ts, segments.ts, io/, editing/ and rendering/; src/io/state-file and src/io/import; src/store/tools, src/core/tools and src/components/tools; src/processing and backend-contract; src/segmentation/components and composables with src/components; then tests.
Each segment actor asked for a coincident-topology polygon offset derived from its place in the registry, on the theory that distinct offsets keep coplanar masks from z-fighting and stack them for the viewer. That never worked. The offset only shifts gl_FragDepth, and a segment actor is translucent, so vtk.js draws it in the order-independent translucent pass, which writes no depth and weights fragments by the un-offset gl_FragCoord.z. The per-segment term changed nothing on screen. The shared part of the offset still matters, since it lifts the segments off the coplanar base image, so it stays as one constant. The stack index that fed the per-segment term is gone from the store, the slice viewer and the representation, and the specs that asserted it now assert the single offset and the registry order the move actually changes.
The `multiple` flag's description claimed the client stages the whole segmentation as one flattened labelmap file whatever the flag says. It does not: a labelmap sourceRef stages overlap-free parts, one staged file each, and the flag decides how many of them are sent. The text now says that true sends every mask across as many files as overlap requires, that false sends only the non-conflicting subset that fits one file and omits the rest whole with a message to the user, and that no mask is clipped. The annotations label colour was an undocumented open string, so a producer had no way to know which syntax the client reads. It now states that a hex value or a CSS colour keyword is accepted and that anything else is ignored, leaving the label the colour the client already holds. The negative-fixture rule promised more than the published schemas deliver: wrong-length-color.json is rejected only by the strict known-intent union, since the published result-intent schema is deliberately open. The README now records that exception where the rule is stated. Generated artifacts regenerated with npm run contract:generate; only these three descriptions changed. The annotation label schema also says that fillColor is ignored.
A hidden segment kept its slice actor visible and drew it at zero alpha, so every render still traversed and drew one actor per hidden segment per view. The actor now follows the segment's visibility as well as its slice extent. With 118 imported segments hidden, render time while painting fell from about 390 ms to about 120 ms per second of stroke in a development build.
PaulHax
force-pushed
the
segmentation-integration
branch
from
September 21, 2026 22:14
59a436e to
2896997
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds on #962.
One image-scoped segmentation replaces segment groups. This adds the store that
owns mask identity, attachment and lifecycle; labelmap import, restore and
interchange; the paint, polygon and process editing paths with their
algorithms and workers; the slice representation; manifest 7.0.0 serialization
with migration of legacy state; the annotation tools and stores retargeted at
segment identity; processing inputs bound directly to segmentations; the flat
segment list with sidebar controls, shortcuts and eyedropper; and the unit and
end-to-end coverage. It deletes the segment group store, its view config and
the old controls.
Suggested reading order: src/segmentation/store.ts, segments.ts, io/, editing/
and rendering/; src/io/state-file and src/io/import; src/store/tools,
src/core/tools and src/components/tools; src/processing and backend-contract;
src/segmentation/components and composables with src/components; then tests.
The commits after the first are fixes, performance work and tests for the code this change adds. Each is its own commit with its own message, in the order they were written.