Encircle is a cross-platform imaging toolkit that affords a natural user interface for 3D image visualization, 3D reconstruction, arbitrary slicing, and much more.  Encircle is a novel technological foundation that allows for the generation of state-of-the-art 3D imaging applications.

Encircle is the harmonious integration between a high-performance 3D imaging toolkit and a user interface widget library. Patented technologies form this union by aligning design paradigms between the two. This saves the software developer substantial time and allows them to focus on scientific problems at hand when developing complex high-performance applications. This saves time, money, and makes our software developers more efficient at solving difficult real-world software problems.


Stratovan Encircle™ is a cross-platform foundation tailored to imaging applications. The complexity of imaging software demands harmonious integration of numerous technologies. Encircle incorporates patent-pending user interface technology that permits natural user interface evolution while minimizing internal changes to data structures, algorithms, and connective logic. Encircle minimizes the complexity in creating multi-target commercial quality applications that look and act like native software. On a Mac it looks like a Mac application and on Windows it looks like a Windows application.
Encircle reduces the complexity of connecting user interface (UI) elements to complex data structures and algorithms.



Measuring the complexity of a user interface is challenging. Tangible metrics such as lines of code and required level of understanding are both reduced using the Encircle platform. However, it is the intangible issues that contribute to complexity in difficult to measure ways. Consider these questions in regard to your current platform of choice and how they contribute to your everyday workload:    

  • How do you position widgets in a UI layout?
  • How is the UI context (i.e., a list box selection state) accessed by application data structures and algorithms?
  • How do widgets get their data?  
  • What percentage of your time is spent on (re-)wiring UI elements to data structures compared to high-value time spent on data structure and algorithm development?

Furthermore, consider how each of these issues affect late-stage UI design changes. Typically, these issues result in several hours/days of work for minor UI changes, such as moving a button or changing the window hierarchy.

  • Cross-platform development: Windows and OSX.
  • Integrated multi-processor threading support.
  • OpenGL integration and substantial support for hardware accelerated graphics.
  • Integrated software licensing.
  • Common mathematical methods and linear algebra tools.
  • Medical imaging data structures, tools, visualization, 3D reconstruction, slicing, and more.
  • Includes Stratovan Relay&trade, a patent pending resolution independent user interface design technology.
  • Hundreds of miscellaneous data structures, algorithms, and tools for image processing and 3D manipulation.
  • Integrated landmark editing system.
  • Easy to use user interface widget layer.
  • Patent pending centralized selection context for handling selection state throughout a software application.
  • and more...
User Interface Layout Technology

Encircle Layout Technology

Stratovan Relay™ is a patent-pending resolution independent layout technology that bases runtime widget resizing and positioning on two source layout designs. The UI designer specifies a small and large layout so that the widgets are positioned correctly for each size. During runtime, Relay automatically determines the size and position of each UI element based upon the runtime width and height of the layout.

The following images show an actual UI designed using Relay technology and the corresponding runtime layouts (click on each image to enlarge):


Small Design
(228 x 264)

Small Design

Large Design
(1580 x 936)

Large Design

(891 x 827)

Runtime (891 x 827)

(1525 x 339)

Runtime (1525 x 339)

(1914 x 1071)

Runtime (1914 x 1071)

Conventional Layout Technologies

Consider these questions for your current widget platform:

  • How do you position widgets in a UI layout?
  • How is resizing of widgets handled?
  • Does the resizing/layout logic require any hand/manual coding?
  • Does the widget/window hierarchy play a role in layout?
  • How much effort is required to change a UI layout several years into product development?
  • Is your layout system resolution independent?

Conventional layout technologies:

  1. Are based on one design layout and cannot resize (at all) during runtime.
  2. Are based on one design layout and require hand-coding to achieve runtime resizing
  3. Are entirely hand-coded.
  4. Use widget edge-relationships to establish resize logic.
  5. Use fixed dimensions or ratios of the width/height to determine size and position.
  6. Require hours of work to change.
  7. Never seem quite right during runtime.
  8. Are NOT resolution independent.
Selection Management and Data Binding

Centralized Selection Context

Stratovan Encircle™ integrates a patent-pending centralized selection context for widgets. The technology pulls the selection state for each widget out of the widget itself and places it in a centralized storage that can then be queried, updated, or listened-to from any portion of the application.

Centralizing the runtime UI selection context has a profound effect on reducing the complexity of data binding between the UI widgets and your data structures and algorithms. The following image shows a diagram of the conventional selection context in relation to data binding:

Convention selection management

Under this paradigm, the application developer must mediate between the widgets and data structures and algorithms (data storage). The mediator must query widgets for selection state, retrieve the appropriate data, and then provide that data directly to each widget. This results in several direct connections to widget objects. These direct connections are the main source of complexity that prevent late-stage UI changes.

Some widget toolkit vendors recognized the difficulty with providing data to widgets and added direct data binding to alleviate the issue:

Conventional selection with direct data binding

While direct data binding alleviates the issue of getting data into a widget, the application developer must still query widgets directly to obtain their selection state in order to determine which data the widget displays. Thus, direct connections to widgets are still commonplace under this modified paradigm.

Encircle combines direct data binding with a centralized selection context in the following manner:

Centralized selection context with direct data binding

This paradigm eliminates all direct connections between widgets to internal data structures and algorithms. Flexibility is obtained by connecting through generic direct data binding interfaces in addition to connecting to the central selection context. This results in a less complex mediator and minimizes the maintenance of the "wiring" between widgets and data. Since the UI connections are simplified, late-stage UI changes (i.e., moving widgets around based on user studies and requests) are now easily incorporated.


Conventional Selection Management

Consider these questions for your current widget platform:

  • How is the UI context (i.e., a list box selection state) accessed by data structures and algorithms?
  • How does one widget access the selection context of another widget?
  • Does the toolkit developer or the application developer (you) manage the UI selection context?
  • Does the widget/window hierarchy play a role in selection management/access/routing?
  • Is there a delineation between commands and selection state changes?
  • How do custom controls share/access selection context information?

Conventional paradigms are widget-centric in that widgets "own" their selection state. This requires the application developer to query each widget when the selection state is needed. Consider how a list box maintains selection state and how it must be queried to obtain it within an application. A widget-centric paradigm results in:

  1. Direct connections from widgets to data structures and algorithms.
  2. Multiple copies of selection state in different widgets that indicate the same selected data.
  3. Complex handlers for selection state changes as well as direct connections to widgets.
  4. Complex relationships in window hierarchy and selection state update routing.
  5. Inflexible logic for coping with widget selection state changes.
  6. Direct connections to other widgets for the purpose of propagating selection

Conventional Data Binding

Consider these questions for your current widget platform:

  • How do widgets get their data?
  • How are widgets connected to data?
  • Does the widget/window hierarchy play a role in data binding?
  • How does UI selection context affect widget data?
  • Does your current widget toolkit dictate internal data structures?
  • How are widgets attached to hierarchical/nested data?
  • How are widgets notified when their underlying data has changed?

Stratovan Encircle™ utilizes a class-centric notification mechanism. It is class-centric in the sense that the specific notifications (messages, connection points, etc.) are defined relative to a specific class. This is counter to conventional paradigms that tend to use a numeric counter or ID, which can easily lose integrity in large software projects.

Encircle differentiates between the following notification types:

  • Command - i.e., when a button is clicked
  • Selection set - i.e., denotes which list box item is selected
  • Datum - i.e., a specific class member variable
  • Class ID - i.e., a class ID useful for serialization
  • String - i.e., accessing application strings from anywhere in the implementatio

To add a new notification, you declare the notification in the class in which it is associated using one of the following mechanisms:

  • COMMAND_DECLARATION( classnamecommandname )
  • SELECTIONSET_DECLARATION( classnameselectionsetname )
  • DATUM_DECLARATION( classnamedatumname )
  • CLASSID_DECLARATION( classname )
  • STRING_DECLARATION( classnamestringname

The above declarations are placed within the enclosing backets of the classname (in a public section) and can be referred to in any part of the application using the following:

  • TYPE_COMMAND( classnamecommandname )
  • TYPE_SELECTIONSET( classnameselectionsetname )
  • TYPE_DATUM( classnamedatumname )
  • TYPE_CLASSID( classname )
  • TYPE_STRING( classnamestringname )


Conventional Notifications

Consider these questions for your current widget platform:

  • How are command notifications handled?
  • How do you notify the UI when data changes?
  • Does the widget/window hierarchy play a role in command routing?
  • Is there a delineation between "commands" and selection state changes?

Related Products

$9,999 (USD)
Pro Surgical 3D
$499 (USD)
Automated Threat Recognition (ATR)