Skip to content

OpenIGTLink US messaging proposal

Jump to bottom Edit New page
Christian Askeland edited this page Dec 14, 2015 · 22 revisions

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

The work is based on experience working mainly with Ultrasonix and GE scanners. Another igtl message used by CustusX can be found here. It contains the minimal information required to work with 2D probes, with no control (only status).

Table of Contents

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_IQ (Complex)
    • US_RF (Scalar)
  • 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)
      • Gain
      • Power
      • frequency, send/receive (i.e. harmonic)
      • focus points {array}
    • extension parameters (same as optional, but user-defined, nonstandard)
      • pitch
      • packet size
      • averaging window
      • clarity
      • compounding
      • persist
      • nyquist velocity

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, suggested implementation

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.

The syntax for the message descriptions below are:

MESSAGE_TYPE {device_id} [direction]: Description of message.

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 all scanner properties except the details of each stream.
  • 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

Additional data data related to stream

  • GET_IMAGE{mask_id} [CLI->SVR]: get mask
  • IMAGE{mask_id} [SVR->CLI]: a mask image for the stream associated with mask_id.
  • GET_COLORT{colort_id} [CLI->SVR]: get color table
  • COLORT{colort_id} [SVR->CLI]: a color table for the stream associated with colort_id.

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.

TODO: Server need a way to inform the client what properties are settable.

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.

Todo

  • Consider tracking data vs. coordinate spaces.
  • define xml schema
  • define all properties exactly, ref to DICOM std where possible
  • figure describing probe sector.
  • ECG, physiological data (e.g. respiration)
  • bi/triplane probe, slices from 3D probe: each stream have its own space - already handled
  • out-of-plane focus
  • capabilities, specify what can be set, what happens if an inconsistent state is requested (suggestion: scanner does its best)
Add a custom footer
Add a custom sidebar
Clone this wiki locally