Annotation features mostly related to MultiscaleAnnotationSource #493
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.
All of these were developed for our cave annotation datasource. I could add the cave datasource here or keep it a separate PR, whichever you prefer.
Each of these features still needs discussion.
53821ff
Mostly happy with this but I left out sorting. We don't always want to sort annotations by distance, we often want the order from the server response. We also are only using 1 chunk the size of the dataset for annotations.
cee0146
This feature makes it easier to quickly glance at the annotations, more useful when the segment list is small. Because there can be multiple annotation lists visible at a time, I'm currently relying on tabIndex to make it focusable so I can listen to key events directly on that element. It isn't ideal but it's robust.
8398ac5
A list of enum values colored by a default hash function (exposed in the shader as
hashColor
) appears when hovering overenum
in theneuroglancer-annotation-shader-property-list
.The hashColor function is really nice for quickly making a useful annotation shader. I could add a seed argument. The list element would no longer match unless we started to parse the shader for that which is probably something to avoid.
If I change the shader prop code so that it supports
prop_cell_type == prop_cell_type("b")
instead as you suggested #481 (reply in thread) Does glsl allow prop_cell_type to be both a value and a function or would it be a pre-compilation step?