Layers

See instructions below the demo app UI for how to run this example.

Run it Locally

1. download/clone this repository.
2. in the root directory (vis/) run pnpm install
3. run pnpm build
4. cd site/
5. pnpm run dev
6. navigate to the running app (default localhost:4321/vis). you can click a link to a specific example in the docs, or just use the address bar (localhost:4321/vis/examples/{path_to_desired_example})

Layers Example

Why?

the goal of this (rather complicated) example app is not to show off a cool app - rather its goal is to show that we can build complexity by composing simple, focused modules. As we (the AIBS Apps team) have developed ABC-Atlas, we’ve tried to make sure our visualization code stays general, and that each part does as little as possible. The result is that it was fairly easy to combine those components into this new app, which mixes a (terrible) UI, scatter-plot rendering, polygon-mesh rendering (for annotations) and multi-channel volumetric rendering into independent layers. Although each of these data types appear different, our caching, fetching, visibility determination, and render-scheduling code is the same regardless of the datatype to be rendered. All that is required is to fill in a simple interface, and provide a low-level “renderer” plugin in order to add a new “layer” type.

Demo Script

Programmatic Configuration

After starting the app in a browser, you’ll be greeted by a blank screen. We’re going to demonstrate programmatic access to the features of this demo. The goal here is not to make users invoke command-line arguments, but rather just an easy way for interested parties to “peak under the hood”. All the visualizations are configured here via simple json objects - it would not be a stretch to read these configuration options at initialization-time via URL parameters for example.

Open your browser’s developer tools via ctrl+shift+i, ctrl+opt+i, or F12, and go to the developer console tab. This console is a running REPL environment with direct access to the demo. You can explore what features are available by typing “demo.” at which point you should be given some auto-complete options, corresponding to the methods available on the demo object. The first thing we should take a look at is demo.addLayer, which accepts a configuration object for some data to be viewed as a layer in the app. A list of pre-constructed objects is provided in the examples object. lets run examples.reconstructed to take a peek:

  "type": "ScatterPlotGridConfig",
  "colorBy": {
    "name": "88",
    "type": "QUANTITATIVE"
  },
  "url": "https://.../4STCSZBXHYOI0JUUA3M/ScatterBrain.json"
}

note - the above config has been slightly altered here for readability!

Some things to observe about this config object:

1. its simple json
2. the “type” tag tells the app what fields to expect next.
3. this data is a grid of scatter-plots (slide view!), its colored by a quantitative feature (gene #88).
4. lastly - do not take this structure too seriously! I made up all the layer-config types in a hurry, and we can easily make new ones, compose existing ones, or change anything at all!

Explore a few layers

Lets continue by adding one layer: demo.addLayer(examples.reconstructed) now, we should be able to navigate the (previously blank) view with the mouse, and we can watch the data load as it becomes visible (and thus, worth fetching & caching). Note also that the UI populates, with very simple (ugly?) controls to change settings, in this case only the gene by which to color can be edited. This ui took about 60 seconds to write, and I would not hesitate to throw it away. Lets add a second layer: demo.addLayer(examples.structureAnnotation) This data is the CCF annotations (the regions to which the scatterplot data is registered), and should line up with the scatterplot grid. This layer type has only a few simple options for altering the opacity of the polygons. Lets add another layer: demo.addLayer(examples.tissuecyte396) This should load up a contact-sheet style view, with 142 slices. You should note that the slices are not expected to line up with those in the other two layers (the slide-view scatterplot) - the data in each are in different coordinate systems. Perhaps obviously, the whole point of having multiple layers in one view would be to observe interesting relationships between them, and in a (non-demo) app, it would be important to allow configurations to specify mappings / transforms / etc. to get things to “line up”. You should also see some double-post, “invlerp” sliders that control how the raw channels of information get mapped to visible-light color. You should be able to move the min & max for each channel, although do note that there seems to be very little data in the 3rd channel, mapped to the color blue.

Take a picture

At the top left of the UI, you might notice a little 📸 button. This will take a low-resolution snapshot of the current view. If you’d like to be a little patient, enter the dev console again, and run demo.requestSnapshot(10000) which, depending on the aspect ratio of your browser window, will (slowly!) capture an ~80 million pixel image of the current screen - the main reason its slow is because, to properly serve that higher resolution, the rendering system must fetch many, many chunks of high-resolution data to render. Note that making changes to the UI during the snapshot process may cause those changes to take partial effect in the final snapshot output. This is a well understood class of bugs that are easy to address when planning to “do software correctly” - however this is a quick demo so I took a bunch of shortcuts!