Application Hosting

1
Application Hosting

• WG-23 Status Report 29 October 2007

2
Targets for WG-6

• Overview for WG-6 today
• Review for Public Comment in March 2008
• Frozen Draft in May/June 2008
• May decide to ballot early if implementations are
  far enough along
• Ballot Fall 2008

3
Basic Goals of Supp. 118

• Simple encapsulation of existing applications
• Self-contained applications
• Data exchange via files (e.g. Part 10 format)
• Ease development of new applications for DICOM
  novices
• Simple abstract model
• Hosting System parses and builds DICOM objects
• Full native access available if needed
• Use existing technology where practical

4
Out of Scope for Supp. 118

• Full integration into the Hosting System GUI
• No standard GUI widgets
• However, host may provide rectangular screen area
  recommendation to cooperating applications
• Discovery
• No standard service for locating suitable
  applications on the Internet for installation
• No mechanism for determining what applications
  are installed on the Hosting System
• Access to DICOM services beyond storage

5
In Debate

• Formalized description of applications
• Against not enough time to get it right
• For needed to verify application ID (e.g.
  signature)
• Alternative a paper-based description
• Start-up method command line arguments
• Against does not cover all start-up methods
• For simple, available on most systems
• Alternative 1 well-known port
• Alternative 2 args, with well-known port
  fallback
• Alternative 3 leave it open, let host decide

6
Application Initialization

• Hosting System locates desired Application using
  mechanisms outside of the standard.
• Hosting System initializes the Hosted Application
  using the equivalent of a run or exec
  command.
• Hosted Application utilizes command line
  arguments passed by the Hosting System to connect
  to the Host interface, and to present the
  Application interface.
• If no command line arguments, the Hosted
  Application utilizes a well known port to
  obtain the needed information for connecting to
  the Host interface, and to present the
  Application interface.

7
Two Main Interfaces

• Application holds methods that the Hosting
  System uses to control and feed data to the
  Hosted Application.
• Host holds methods that the Hosted Application
  uses to communicate outputs to the Hosting
  System, and to notify it of status and state
  changes.
• One-to-one correspondence of instances of the
  Host and Application interfaces.
• Interfaces are defined in WSDL to be language and
  platform independent.

8
Application Methods

• setState(state State) boolean
• getState() State
• bringToFront() boolean

9
Host Methods

• notifyStateChanged(state State) void
• notifyOutputAvailable() void
• notifyStatus(status Status) void
• getTmpDir() String
• getOutputDir() String
• generateUID() String
• getAvailableScreen(appPreferredScreen
  Rectangle) Rectangle

10
Application States

• IDLE waiting for next task
• INPROGRESS performing task
• COMPLETED task done, wait for Hosting System to
  grab output
• SUSPENDED task is not finished, but no
  processing is being done
• CANCELED kill the task and release resources
  with no further output
• EXIT destroy this instance of the application

11
(No Transcript)
12
Application Running

• On start-up, the Hosted Application waits in the
  IDLE state.
• The Hosting System triggers a task by changing
  the Hosted Applications state to INPROGRESS.
• Hosted Application grabs the input data.
• The Hosted Application only handles one task at a
  time.
• The Hosting System may simultaneously start
  multiple Hosted Applications, including more than
  one running instance of the same Hosted
  Application.

13
Application Suspend

• The Hosting System may pause a running Hosted
  Application by changing the state from
  INPROGRESS to SUSPENDED.
• When suspended, the Hosted Application minimizes
  resource use without loosing task context.
• The Hosting System asks the Hosted Application to
  continue processing the task by changing the
  state to INPROGRESS.

14
Application Cancel

• The Hosting System kills a running or suspended
  task by changing the Hosted Applications state
  to CANCELED.
• The Hosted Application aborts processing,
  releases all resources, and returns to the IDLE
  state, waiting for the next task.

15
Application Task Completion

• When the Hosted Application has completed its
  task, it changes its state to COMPLETED and
  notifies the Hosting System of the state change.
• When the Host System has collected the output
  data, the Hosted Application changes state to
  IDLE, and notifies the Hosting System of the
  state change.

16
Application Termination

• If the Hosted Application is in the IDLE state,
  the Hosting System may terminate the Hosted
  Application by changing the state to EXIT.

17
Condition Handling

• If there is a notable condition (e.g. a progress
  report, an error) in the Hosted Application, it
  may inform the Hosting System via a
  notifyStatus() call.
• The Status includes
• statusType (i.e. INFO, WARN, ERROR, FATAL)
• codingSchemeDesignator
• codeValue
• messageString

18
Data Exchange

• File Access Methods
• Simple exchange of files (e.g. DICOM Part 10)
• Can support other file formats (e.g. Analyze)
  used by researchers
• Furthest along (essentially finished)
• Model Access Methods
• Both Native (e.g. DICOM models) and Abstract
  (e.g. Multi-Dimensional Image) versions
• Uses commonly available tools that are often used
  to process XML
• Is independent of the underlying data format

19
File Access Methods

• getNativeObjectDescriptors() NativeObjectDescrip
  tor
• getAsFile(desireObjects NativeObjectDescriptor
  ) NativeObjectLocator

20
Native Object Descriptor

• Consists of
• UUID String
• MIMEType String
• SOPClassUID String
• Used to describe the native form of one object
  (e.g. a DICOM Part 10 file)
• UUID used to
• Avoid potential collisions with SOP Instance UID
• Maintain generality

21
Native Object Locator

• Consists of
• referencedUUID String
• uri URI
• referencedUUID, which identifies the object, is
  taken from the Native Object Descriptor
• The uri identifies the location of the desired
  object (i.e., the file)

22
File Exchange Sequence
Recipient
Sender
getNativeDescriptors()
return of NativeDescriptors
getAsFile( targets NativeDescrptors)
return of NativeLocators
23
Symmetric File Exchange

• File Exchange methods are symmetric (i.e. the
  Hosted Application uses the same methods to get
  input data from the Hosting System that the
  Hosting System uses to get output data from the
  Hosted Applications)
• Once the recipient asks for a Native Object
  Descriptor as a file, and the sender responds,
  then the sender takes the object off of the
  Native Object Descriptor list

24
Model Access Methods

• Derived from Java Image IO concepts
• Abstract access to common data
• Generic mechanism to access format-specific data
• Utilizes the XML Infoset concept
• Hosting System maintains a model of the
  referenced data, e.g. using DOM tools
• Using DOM does not mean that the data ever
  existed natively in XML form
• DOM is a convenient way to describe the layout of
  the data, even if the data is in DICOM format
• Hosted Application utilizes XPath to identify the
  desired data

25
Example XPath for Native Model

• /DicomObject/ViewCodeSequence/Item_at_number1/
  CodeMeaning/value_at_number1
• Will add a column to Part 6 Data Dictionary for
  properly formatted tag IDs
• Will have provisions for proper Private Data
  Element access
• Can access by Group and Element Tags instead of
  by tag ID

26
Alternative Without XPath

• getNativeMetadata()
• .getElementsByTagName(DicomObject).item(0)
  ()
• .getElementsByTagName(ViewCodeSequence).
  item(0)
• .getElementsByTagName(Item).item(0)
• .getElementsByTagName(CodeMeaning
  ).item(0)
• .getElementsByTagName(value)
  .item(0)
• .getNodeValue()

27
Proposed Model Methods

• Get Abstract Object Descriptors
• Alternative to getNativeObjectDescriptors()
• Hosting System creates Abstract Models as needed
• Returns Native Descriptors if not part of an
  Abstract Model
• Get/Set XPath
• May return single values or Infosets
• Set may be restricted to values
• Asymmetric
• Hosting System manages the creation of models
• Create new models related to old ones
• Allows Hosting System to track info needed to
  serialize the object in DICOM
• Allows Hosting System to add derived references

28
Abstract Model (in development)

• Make life easier for the application developer
• Draws simplified concepts from the new DICOM
  enhance multi-frame objects
• Only commonly used dimensions included
• References the source native models if an
  application needs full details
• Assumes cooked data, e.g.
• Modality LUT applied
• Clean data (sign extended, no overlay bits)
• Data from old style SOP Classes reorganized
• Pixel interleaved color only
• Signed unsigned integers, single double
  floats
• Semantic intent and units included

29
Access to Bulk Data

• Frame is the smallest common denominator
• Bulk Data References done as file locators plus
  offsets to start of data
• Can be read in with normal I/O, or
• Can be accessed as memory-mapped files

30
Implementation Status

• Three independent implementations of earlier
  version as proof of concept, including Java and
  .net versions interoperating
• Primitive performance benchmarking
• Two independent implementations of the file-based
  proposal
• Methodology similar to the model access methods
  used in other projects
• Memory-mapped access used in other projects

31
Driving Forces

• The eXtensible Imaging Platform project from
  NCIs caBIG program
• First open source release due 15 December 2007
• Hands on demonstration at RSNA 2007
• Hands on tutorials at SIIM 2008
• Initial focus on analysis applications for trials
• Two hour workshop at Medical Imaging 2008
• Multiple implementers

32
caBIG will facilitate sharing of infrastructure,
applications, and data
33
Core Principles

• Common, widely distributed informatics platform
• Shared vocabulary, data elements, data models
• Common standard for developing applications

34
(No Transcript)
35
In Vivo Imaging Workspace

• Middleware
• NCIA
• geACRIN
• AIM
• XIP

36
What is the ?

• The eXtensible Imaging Platform (XIP) is the
  image analysis and visualization tool for caBIG.
• XIP is an open source environment for rapidly
  developing medical imaging applications from an
  extensible set of modular elements.
• XIP may be used by vendors to prototype or
  develop new applications.
• Imaging applications developed by research groups
  will be accessible within the clinical operating
  environment, using a new DICOM Plug-in interface
  first implemented in XIP.
• XIP may server as a reference implementation of
  the DICOM WG-23 Application Hosting interfaces.

37
(No Transcript)
38
(No Transcript)
39
XIP Plug-in Architecture
XIP Host
40
DICOM Plug-in Framework

• WG-23 addresses clinical integration and vendor
  inter-operability by defining standardized
  plugs and sockets (APIs)
• caBIG XIP addresses an open-architecture,
  open-source integrated development environment
  for rapid prototyping collaboration based on WG
  23 APIs.

XIP developed Application
Standard API

Unix, Mac, PC
Internet Server
Commercial Vendor 2
Commercial Vendor 1
? Prototype Collaboration ?
? Clinical ?
41
After Supp. 118?

• Work item proposal for Phase 2 at spring 2008
  DICOM Standards Committee meeting
• Phase 2 will fill holes from Phase 1 (e.g. some
  of the out of scope for 118 issues)

42
Abstract metadata for multidimensional image data
considered as functions

• B Gibaud
• 25/10/2007

43
Goals

• Provide documentation of the bulk data
• Concerning
• logical organization
• Range of the function scalar or not, data type
  used (uchar, char, int, float, double, etc)
• Domain of the function Number of variables,
  order of variables, number of samples along each
  dimension, regular sampling or not
• Semantics
• Of components
• Of variables

44
Spec of domain and range

• Range (components)
• Scalar
• Data-type, e.g. int32
• Semantics, e.g. T1weightedMRIsignalintensity
• Vector
• Nb-components table of (Data-type, Semantics)
• Domain (variables)
• Nature of interval
• Regular-interval
• Nb-samples inter-sample-distance sample-width
• Non regular interval
• Nb-samples origin table of (dist-to-origin,
  sample-width )
• Semantics e.g. space, time, energy

45
Example 1

• T1weighted MR dataset
• Scalar Range
• Data-typeint32
• Semantics T1weightedMRsignalintensity
• 3 variables
• Regular interval
• Nb-samples256, inter_sample-dist1mm,
  sample-width1mm
• semantics space along X
• Regular interval
• Nb-samples256, inter_sample-dist1mm,
  sample-width1mm
• semantics space along Y
• Regular interval
• Nb-samples120, inter_sample-dist 4mm,
  sample-width4mm
• semantics space along Z

46
Example 2

• fMRI dataset
• Scalar Range
• Data-typeint16
• Semantics T2STARMRsignalintensity
• 4 variables
• Regular interval
• Nb-samples128, inter_sample-dist4mm,
  sample-width4mm
• semantics space along X
• Regular interval
• Nb-samples128, inter_sample-dist4mm,
  sample-width4mm
• semantics space along Y
• Regular interval
• Nb-samples12, inter_sample-dist 9mm,
  sample-width9mm
• semantics space along Z
• Regular interval
• Nb-samples200, inter_sample-dist 1s,
  sample-width0.5s
• semantics time

47
Example 3

• SPECT acquisition dataset (TOMO)
• Scalar Range
• Data-typeint16
• Semantics Number of counts
• 3 variables
• Regular interval
• Nb-samples128, inter_sample-dist4mm,
  sample-width4mm
• semantics space along X
• Regular interval
• Nb-samples128, inter_sample-dist4mm,
  sample-width4mm
• semantics space along Y
• Regular interval
• Nb-samples128, inter_sample-dist 2.81,
  sample-width2.81
• semantics space along theta (projection
  angle)

48
Example 4

• 3D displacement field (non linear registration)
• Vector Range
• 3 components
• (Data-typefloat Semantics space
  displacement along X)
• (Data-typefloat Semantics space
  displacement along Y)
• (Data-typefloat Semantics space
  displacement along Z)
• 3 variables
• Regular interval
• Nb-samples256, inter_sample-dist1mm,
  sample-width1mm
• semantics space along X
• Regular interval
• Nb-samples256, inter_sample-dist1mm,
  sample-width1mm
• semantics space along Y
• Regular interval
• Nb-samples120, inter_sample-dist 4mm,
  sample-width4mm
• semantics space along Z

49
Example 5-1

• RGB 2D image
• Vector Range
• 3 components
• (Data-typeint16 Semantics Luminance in
  Red)
• (Data-typeint16 Semantics Luminance in
  Green)
• (Data-typeint16 Semantics Luminance in
  Blue)
• 2 variables
• Regular interval
• Nb-samples1024, inter_sample-dist0.5mm,
  sample-width0.5mm
• semantics space along X
• Regular interval
• Nb-samples1024, inter_sample-dist0.5mm,
  sample-width0.5mm
• semantics space along Y

50
Open issues 1

• Need to have a sort of qualitative variable to
  manage e.g. RGB images in 3 separate planes,
  indexed by this variable ?
• semantics of the corresponding variable would be
  Red, Green, Blue ?
• semantics of the corresponding (scalar) range
  would be luminance ?
• Probably needed
• It would become somewhat arbitrary to choose
  between a  vector range  versus a colour
  qualitative variable

51
Example 5-2

• RGB 2D image (as 3 separate planes)
• Scalar Range
• (Data-typeint16 Semantics Luminance)
• 3 variables
• Regular interval
• Nb-samples1024, inter_sample-dist0.5mm,
  sample-width0.5mm
• semantics space along X
• Regular interval
• Nb-samples1024, inter_sample-dist0.5mm,
  sample-width0.5mm
• semantics space along Y
• Qualitative variable
• Nb-samples3
• (Semantics Luminance in Red)
• (Semantics Luminance in Green)
• (Semantics Luminance in Blue)

52
Open issues 2

• Need to manage related variables ? for instance
  in the SPECT example (TOMO), the indexing could
  be done both on the projection angle and on
  time
• Useful ?
• Is sampling necessarily regular with both
  variables (linear relationship between the two) ?

53
Open issues 3

• Need to manage units in which scalar components
  are represented (Hounsfield, NM units, etc.) ?
• Useful ?

54
Example 6

• MR Spectro
• TBD