Introduction

This documentation is for a much older version of cornerstone-tools. While it may still loosely apply, more recent information can be found at https://tools.cornerstonejs.org

In cornerstone, a tool is what makes an image interactive. A tool has the following characteristics:

1. Responds to user input such as mouse events, touch events or key presses. These events can happen on the enabled element or on other HTML controls on the page.
2. May modify the viewport settings associated with an enabled element. (e.g. adjust the zoom or pan properties - done via the setViewport API)
3. May draw geometry on the image (e.g. the line in a length measurement)
4. May draw text on the image (e.g. the length in mm of the length measurement)

Due the variety of image types, user preferences, input mechanisms and functionality, a number of different interaction paradigms are necessary in medical imaging applications. Here are some examples to illustrate this:

Desktop application to view projection radiographs

A desktop application used to only view projection radiographs (e.g. CR or DR) could be designed around using a mouse with a mouse wheel. The functionality exposed would include adjusting ww/wc, zooming, panning and length measurements. The mouse wheel would be used to zoom the image. The UI would present a button for the other tools allowing the user to select which one to use the left mouse button for. For example, the user could press the "WW/WC" button and the adjust the ww/wc by left click dragging. After this, they could select the "Length" button and left click drag to create a length measurement.

Tablet application to view projection radiographs

A tablet application used to only view projection radiographs (e.g. CR or DR) could be designed around using multi-touch gestures. The functionality exposed would include adjusting ww/wc, zooming, panning and length measurements. The pinch gesture would be mapped to zooming. The UI would present a button for the other tools allowing the user to select which tool to respond to pan gesture. For example, the user could press the "WW/WC" button and the adjust the ww/wc by using the drag gesture. After this, they could select the "Length" button and then use the drag gesture to draw a length measurement.

Desktop and tablet application to view CT series

An application used to only view CT series might be designed to support a touch interface or a mouse if present. The functionality exposed would include selecting ww/wc presets and scrolling through the series. The mouse wheel would be mapped to change the visible image in the series and the left mouse button would be used to manually adjust the WW/WC through dragging. There would be a button on the UI for each WW/WC preset - selecting the button would apply the WW/WC preset to the displayed image. The touch drag gesture would be used to change to different images in the series.

The above examples illustrate just a few of the variances in interaction paradigms even for applications providing just a few features. Most applications provide much more functionality than this and the interaction paradigm can be much more complex. New input devices such as Kinect or accelerometers open up the door to some exciting possibilities as well.

The variety of interaction paradigms pose a challenge to cornerstone's goal of enabling interactive medical images. Interactivity requires an interaction paradigm but there is no single interaction paradigm that cornerstone can use that will meet everyones needs. Cornerstone addresses this by providing functionality through several layers allowing developers to choose as many (or as few) layers as they like to accomplish their goals. A few examples of this:

1. A developer building a standard desktop web based application may be fine with the interaction paradigm of cornerstones tools and use them as they are
2. A developer building a desktop web based application for a specialized use case may use some of cornerstones tools but also add in their own custom ones deliver functionality similar to a cornerstone tool but in a different way.
3. A developer building a tablet based application may use some the measurement management capabilities of the tool library only and none of the actual tools
4. A developer building a Kinect based application may use cornerstone to display images only and not use any of the tools library. In this case, they would not include any of the cornerstone tools library at all (as it is packaged in a separate file)