The demo is a very early experimental version, to show the possibilities of how DicomObjects can be used to generate a totally zero-footprint viewer, with no plug-ins whatsoever. There are several design principles:
As much work as possible should occur on the server, and operations here should allow the full power of DicomObjects to be used in an ASP.NET environment.
The mechanism used should allow use on both HTML5 browsers which support the “canvas” element, with sensible fall-back to server rendering for those that don’t
Some images (e.g. colour) are probably best rendered on the server anyway, as it is not subject to windowing.
There should be separation between the “toolkit” elements of the viewer and the “user code” (though how it will be distributed is still open to discussion!)
These goals have been achieved by using a “WebControl”, which generates the basic browser, with use of DicomObjects (full .NET DLL)
DicomWebViewer (derived from WebControl) In C#
“User” code behind (C#)
This approach allows the “user” code to operate by either:
Using “Code behind” as is used in the querying and “reset” buttons, which completely regenerate the control via postbacks (with or without AJAX)
This is shown by the following workflow diagram:
The code behind (VB.NET/C# etc.) sets the properties of the DicomWebControl, including loading images into its Images collections, setting MultiRows etc., just as would be done with a DicomViewer forms control
Once the page is loaded, the control requests details of the images it is to display (but no pixel data at this stage, only size, arrangement, identifiers etc. The control then creates its own HTML for displaying the images, using either HTML5 canvas elements or older IMG elements, according to browser and image type, or preferences set by the code behind.
If the image is being displayed via the canvas element, then pixel data is requested through the listening endpoint - this may be downsampled according the required zoom level. It is then windowed and rendered within the browser.
If the image is being displayed via and IMG link, then a suitable URL is generated (including zoom, pan, window information etc.) and the image is requested through the listening endpoint.
The developer has full access to standard ASP.NET controls and their associated code behind. This is how the server querying is achieved in the sample.
Other features of note:
The “default” 4 image loaded initially demonstrate different capabilities:
Server rendered using “JPG”
Server rendered using “PNG”
Client rendered 8 bit image
Client rendered 16 bit image
The data downloaded for rendering is “downsampled” to match the size of of the area being displayed - there is no point in downloading 3000x4000 pixels to fill a screen area or 200 x 300 pixels!
The code auto-detects if the browser cannot support the canvas element and reverts to server-only rendering on older browsers.
During re-windowing, a 2:1 downsampled copy of the image is used for best speed, which is reverted to full resolution when the mouse/finger is lifted.
On a desktop browser, the mouse controls are:
Left button to re-window
Middle button to zoom (centered at initial click point)
Right button to pan
Double left-click to change to single image view
On a touch-screen (e.g. iPad) the touch controls are:
One finger to re-window
Two fingers to zoom (centered at mid-point of fingers) or to pan
At this stage, there are clearly more features to be added, including: