OpenIGTLink US messaging proposal

This page is part of http://wiki.na-mic.org/Wiki/index.php/2016_Winter_Project_Week:TrackedUltrasoundStandardization.

Table of Contents Complete description of all properties for an ultrasound server: Setting the scanner state Status message format Choices

Complete description of all properties for an ultrasound server:

The following are properties for a server residing on an ultrasound scanner. The structure is given in pseudocode, but the intended format is XML.

Parameters are either required, optional or extension:

• required: Defined by standard. Must be present in order to comply with standard.
• optional: Defined by standard. Might be present, if available from scanner and implemented.
• extension: not part of the standard, but added by vendor.

Properties:

• Available_applications { list of names } (list of applications/presets available on the scanner)
• Application_name { name }
• Available_Probes { device_id list } ( List of all probes currently attached to the scanner.)
• Available_Streams { device_id list } (these are an exhaustive list of all stream types that can be of interest from a scanner. Only those supported by the scanner are given. The scalar variants contain raw data, while the RGB/Gray versions are suitable for direct screen display. LUTs can be available when using the raw variants.)
  • Display, (RGB)
  • US_B-Mode (Gray)
  • US_B-Mode-Raw (Scalar)
  • US_Color-Doppler (RGB)
  • US_Color-Doppler-Velocity (Scalar)
  • US_Power-Doppler (RGB)
  • US_Elastography (RGB)
  • US_Elastography (Scalar)
  • US_R0 (Scalar)
  • US_R1 (Scalar)
  • US_RF (Scalar)
  • US_IQ (Complex)
• Probe: {device_id_0} (one probe entry for each probe)
  • probe parameters: Name, Center freq, focus pt, pitch, geometry model..?,
• Stream: {device_id} (one stream entry for each stream)
  • Image Format: {RGB, Gray, Complex, Scalar}. If Scalar, a color table might be available (in a separate field)
  • Probe sector: (A description handling 2D/3D sector/curvilinear/linear probes. Handles most cases, mask handles the rest. TODO: add figure. )
    • origin {x,y} (position of sector arc center in image space)
    • depth start (start offset from origin)
    • depth stop (end offset from origin)
    • azimuth (shape in the azimuth plane)
      • type{linear, sector}
      • width{angle/width}
      • tilt {angle, optional}
    • elevation (shape in the elevation plane, optional, NA for 2D probes)
      • width{angle/width}
      • type{linear, sector}
      • tilt {angle, optional}
    • exact: bool. If false, must use Mask stream to get exact geometry
    • mask {device_id, optional}: a device_id that can be used to GET an IMAGE containing a mask describing the sector.
  • Color table {device_id, optional} If given, points to a device_id that can be used to GET a COLORT, can be applied on scalar image values.
  • optional parameters (name-value pairs, specified by description and value def (unit etc) examples given)
    • frequency
    • harmonic {y/n}
    • focus points {array}
    • pitch
    • nyquist velocity
    • packet size
    • averaging window
  • extension parameters (same as optional, but user-defined, nonstandard)

Setting the scanner state

The scanner can be controlled by sending a state from client to server on a format similar to the one given in the properties section. This requires that the client know the value range, e.g. the available probes in order to set a probe.

The following must be controllable:

• current probe
• current application
• stream on/off for each stream
• probe sector shape for each stream.

Status message format

The status can be organized as a xml document, and can thus be embedded into any text field in any message. XML also provides an easy system for optional and extension parameters. Each DOM-element can contain a reserved extension element. Here custom properties can be added without interfering with the required/optional properties.

The existing STATUS message can be reused for this purpose, or a new similar message can be defined. Status messages are defined for the scanner as a whole, and for each specific stream. The status is sent per stream in order to reduce the amount of information in each message. Note: For each stream there are now two messages: STATUS and IMAGE.

Scanner messages:

• GET_STATUS {no device_id} [CLI->SVR]: Request scanner to return STATUS{scanner_id}.
• STATUS{scanner_id} [SVR->CLI]: A status for the entire scanner, with a XML doc containing only root items (application, available probes, streams, current probe, streams.
• STT/STP_STATUS{scanner_id} [CLI->SVR]: start/stop streaming of scanner status. Status is only sent when changed.
• RTS_STATUS{scanner_id} [SVR->CLI]: reply when start/stop called

Stream status messages:

• GET_STATUS {no stream_id} [CLI->SVR]: Request scanner to return STATUS{stream_id}.
• STATUS{stream_id} [SVR->CLI]: A status for the stream, with a XML doc containing properties for this stream only.
• STT/STP_STATUS{stream_id} [CLI->SVR]: start/stop streaming of stream status. Status is only sent when changed.
• RTS_STATUS{stream_id} [SVR->CLI]: reply when start/stop called

Stream image messages:

• IMAGE{stream_id} [SVR->CLI]: An image from the given stream, corresponding to the status given in STATUS{stream_id}.
• STT/STP_IMAGE{stream_id} [CLI->SVR]: start/stop image streaming.
• RTS_IMAGE{stream_id} [SVR->CLI]: reply when start/stop called

Setting scanner state:

This might be implemented by sending a STATUS containing the modified state from client to server. TBD.

Choices

• By reusing existing messages, we only need to add STT/STP/RTS_STATUS for this to work. Alternative is to be more concise by adding new messages.
• Not added: Available range for all settable properties. Not easy to query on scanners, overkill.
• Not added: General catch-all geometry description for sector. The proposal catches all normal cases, while the Mask Stream provides an exact description of other cases.