A few questions about Atlas viewer

[WilliamDiakite]

Hi @stephenwf!

I'm trying make sense of the IIIF eco-system which is new to me and I would have a few questions about Atlas viewer if you don't mind:

1. do you plan on releasing the atlas viewer as a public package or will it be a private module for canvas-panel?
2. if it is released, under what licence?
3. if released, when can we expect to see an alpha/beta version of the viewer?
4. how would you describe Atlas viewer compared to OpenSeadragon? From what I understand so far, Atlas is a modernized / high performance version of osd.

Thank you in advance for your time!

[stephenwf]

Hi @WilliamDiakite

Thanks for checking out canvas panel and Atlas viewer!

1. Atlas is currently available on NPM @atlas-viewer/atlas although at the moment the API is likely to change. There is a test-driven rewrite running in parallel that will hopefully mark the point where the viewer can be more widely used standalone without a wrapper like canvas panel.
2. MIT - I've added this to the repo to clarify (was marked in the NPM package)
3. An alpha is available now, and can be picked up from NPM, the latest is 2.0.0-alpha.16. There are 2 main ways of working with Atlas, the first is React-based and the other is vanilla javascript. The API tries to emulate the DOM api in many ways, so should feel familiar.
4. Atlas and OpenSeadragon are similar in the goal of displaying deep zoom content, but are quite different in the way they work. I'll try to highlight the key differences.

DOM-like API

When you add content to OpenSeadragon you can add 2 types of resource: A tile source (image) or an overlay (html). These are added and positioned in a "world" so you first figure out where everything needs to go - and then you add it to OpenSeadragon. This is a fairly flat structure where a world contains a list of images and overlays.

Atlas is a tree-structure, where you can create "containers" and position multiple images relative to that container. Each image or other resource is positioned for you relative to that container, so you can move it around and everything stays where you put it. This is modelled after the IIIF Canvas and means you can maintain the same concepts from IIIF (like annotation positions) in your viewer.

const world = new Atlas.World();
const object = new Atlas.WorldObject();
const image = new Atlas.SingleImage();

// Set up a container
object.applyProps({ height: 1024, width: 1024 });

// Add our image
image.applyProps({ uri: '...', target: { height: 1024, width: 1024 } });
object.appendChild(image);

// Add to container world
world.appendChild(object);

An example here looking in dev-tools you can see the tree of objects (with a few HTML overlays):




Modular

At the moment Atlas is very modular, to the point where it's not very easy to set up quickly yet. The main idea is that Atlas isn't tied to any particular rendering strategy. At the moment it can render as HTML images, an HTML canvas or WebGL canvas. The modular parts are:

• Renderer - Examples include CanvasRenderer, StaticRenderer, WebGLRenderer and OverlayRenderer for displaying content.
• Event manager - Binds native events (e.g. browser) to Atlas internal events
• Controller - Adds interactivity (pan, zoom, etc.) using Atlas events.

A few examples of what this allows (or could allow):

• Rendering HTML for non-interactive viewers
• Server-side rendering of full viewers
• Static -> Canvas on interaction

A small detail, but Atlas tries to "run cold" and if there are no interactions, there will be very little javascript running in the background. The difference between have 1 and 50 viewers on a page should be minimal.

Events

Both OpenSeadragon and Atlas have support for events (clicking on an overlay for example). OpenSeadragon has a MouseTracker where you can attach events to objects you've added, whereas Atlas tries to emulate the way browsers handle events.

OpenSeadragon events example

```js OpenSeadragon({ ... preserveViewport: true, showNavigator: false, sequenceMode: true, overlays: [{ px: 6425, py: 0, id: 'html-overlay' }], tileSources: [{ width: 6425, height: 8535, tileSize: 256, tileOverlap: 1, getTileUrl: chronicling_america_example(1) },{ ... }] }).addOnceHandler('open', function(event) { ... // MouseTracker is required for links to function in overlays new OpenSeadragon.MouseTracker({ element: 'html-overlay', clickHandler: function(event) { var target = event.originalEvent.target; if (target.matches('a')) { if (target.getAttribute('target') === '_blank') { window.open(target.getAttribute('href')); } else { location.href = target.getAttribute('href'); } } } }); }); ```

Atlas example

const object = new Atlas.WorldObject();
const image = new Atlas.SingleImage();
const overlay = new Atlas.Box();

// Bind events like DOM elements:
image.addEventListener('click', e => {
  e.atlasTarget // Atlas.WorldObject
  // position in world
  e.atlas.x;
  e.atlas.y;
});

// Stop events being propagated
box.addEventListener('click', e => {
  e.stopPropagation(); // parent events won't be called
});

The purpose of this is to enable much more interactivity in the viewer, and make more complex interactions composable. We are using this to drive some on-canvas editing and dragging around resources.

Performance

OpenSeadragon and Atlas have a different balance in terms of performance. OpenSeadragon has much more capabilities and is much more stable with its feature set. Atlas does less, faster. The WebGL renderer is great, but does require images to be served with CORS - so is not a silver bullet. I think the important thing is that performance isn't a problem in Atlas, so other factors can help if deciding between.

There are other differences, but these are the main differences that I think are worth highlighting!

[WilliamDiakite]

@stephenwf,

I cannot thank you enough for this detailed answer, the information I found here is so valuable! Thank also for the npm link, I can't wait to try Atlas viewer.

By the way, I just saw from the Atlas dependencies (on the npm page of atlas) that you were using (among other) the iiif/vault and iiif/presentation3. Does this mean that, like canvas-panel, Atlas will be able to handle IIIF manifests?

Again thank you for your time and work!

[stephenwf]

It supports the IIIF Image API but won't be quite as seamless as Canvas Panel (but you do get full control). You will still have to load and parse the manifest and then pass down the image service.

Vault and Vault helpers in IIIF Commons will hopefully be the glue in the middle to make it easy to render all types of IIIF in various viewers (including Atlas)

[WilliamDiakite]

Ok great, thank you so much!