More support for string/enum annotation properties and being able to view a list of active external annotations

[chrisj]

We have properties like cell types associated with annotations. We want to be able to color code and basically have an easier way to interact with the types in the shader.

Here is an example of using the data. https://cj-cave-anno-share-dot-neuroglancer-dot-seung-lab.appspot.com/#!middleauth+https://global.daf-apis.com/nglstate/api/v1/4574280069152768

I map each unique string value to an incremented value. I see how we can use the enum values/labels to make that more polished. We also could add support in the backend so that mapping is consistent.

Alternatively maybe it would be ideal to hide that from the user and have the user be able to write shader code that uses the string values directly.

Similar to the segment color hash, we could add the option to generate a color based on the property value so that users don't have to set up a complicated shader though it would still be important to also be able to see the mapping somewhere. Perhaps it would be enough to just see it in the selection panel for an individual annotation.

I've also been requested that it would be very useful to be able to have a list of the active annotations within the annotation tab. There currently is an empty list. I haven't seen a neuroglancer link with a list of external annotations. I think we would like it even when it is an unrestricted spatial query.

[chrisj]

I'm willing to work on implementing both of these features but before I get too deep, I want to make sure these sound like the right direction to go.

I'm less sure about having an annotation list because the backend immediately converts the annotations to geometry data so would that require me to refactor the annotation source to keep the annotations as well as the geometry data? It probably should be optional.

Regarding supporting enums in the shader. I'm imagining we have

enum_values: [1,2,3],
enum_labels: ['a', 'b', 'c']```

void main() {
  setColor(defaultColor());
  
  if (prop_cell_type() == enum("b")) {
    setColor("bCellColor");
  }

Gets compiled to

void main() {
  setColor(defaultColor());
  
  if (prop_cell_type() == uint(2)) {
    setColor("bCellColor");
  }

[jbms]

To allow the enum keys to appear in the shader, there are two options that I can think of:

• inject #define statements so that the enum values are available as constants, e.g. prop_cell_type_b, or use a new syntax, like prop_cell_type("b") that would be handled by source code transformation. We can't just use enum("b") because there may be more than one enum.

For colors, we could add a new shader ui control, colorhash, parameterized by the name of property to be transformed into a color, where the UI control just lets you change the hash seed. Maybe optionally it could also include a color legend. Then as a special case if there is exactly one colorhash control for a given enum, show the corresponding color in the selection details panel as the background color for the value.

[chrisj]

I'll ask around to see what people prefer, yeah I forgot about multiple properties which is the norm for our tables.

So it would either look like

if (prop_cell_type() == prop_cell_type_b) {

or

if (prop_cell_type("b")) {

Define feels like the correct way to implement it though the latter allows for cleaner user-facing shader code and being able to support any string value (no need to convert spaces or other characters that might cause a variable name issue.

[jbms]

I actually was imagining prop_cell_type == prop_cell_type("b") as that allows more flexibility in the shader code even though it is more verbose.

[jbms]

As far as the annotation list, agreed that it would be useful. It could be done based on the binary representation of the geometry, and perhaps decode back into JavaScript objects only the annotations in the visible portion of the list.

I think ideally it would be sorted by distance to the center position.