OpenIGTLink/Discussion/NewCommands

Common GET_LIST message ?

A common GET_LIST message could be defined with the data type, like IMAGE, in the device name field. The answer could be a LIST message with ids (each 20 bytes, so they can be used as device names) of available data. Afterwards a GET_xy message with the id could be used to query the details.

Well, I don't think this will help much in practice.

Example: an application would like to show a list of available images before querying them from the server. Ids are not very specific, so an additional meta data message must be defined. So we have a) GET_LIST and b) for each id: GET_IMGMETA. It would be easier to get all the meta data at once, which returns a list of meta data.

Next example: all ficucial points shall be queried. A two-step mechanism would result in 1+n queries, whereas getting all points at once would end in only 1 query. Even if the user would like to get only 1 specific point, how could he know which id to use?

Another reason is that sending all the data at once is much more efficient.

However, there might be use cases, where single items are useful. If the item size is constant, it makes no difference if only one or several items are transmitted. The number is bodySize/itemSize. Using this definion, single items can still be pushed over the network as it's currently done in most OpenIGTLink applications.

GET messages

Get messages are not well defined yet. The following things should be fixed:

* If 0 items are available, the bodysize of the answer might be 0.
* If an error occurs while processing the request, a STATUS message shall be returned.

Image data

I would like to introduce a GET_IMGMETA message. This get-message has no parameters. The answer is IMGMETA:

Data	Type	Description
Name	char[64]	Pretty name of the image
Id	char[20]	Id to query the IMAGE and COLORT
Modality	char[32]	String which specifies the modality
Patient name	char[64]	Name of the patient
Patient id	char[64]	Id of the patient
Day	8 bit unsigned	Scan day
Month	8 bit unsigned	Scan month
Year	16 bit unsigned	Scan year
RI, RJ, RK	16 bit unsigned	Number of pixels in each direction (same as in IMAGE)
S	8 bit unsigned	Scalar type (e.g. 3:uint8, 5:uint16, same as in IMAGE)

* More than one item can be transmitted. The number is bodySize/itemSize.
* To get the IMAGE, GET_IMAGE is used with the Id in the device name field.
* To get the COLORTABLE, GET_COLORT is used with the Id in the device name field. See Standard OpenIGTLink Protocol description -- Version 2 draft for details.

Point or fiducal data

Currently only transformations can be sent with OpenIGTLink, but especially points like fiducals or trajectories consist of more than a transformation.

GET_POINT is used to get all the point data. It has no parameters. The answer is a POINTS message:

Data	Type	Description
Name	char[64]	Pretty name of the point data like "Fiducal behind left ear"
Group name	char[32]	Can be "Labeled Point", "Landmark", "Fiducal", "Trajectory", ...
Type	8 bit unsigned	1: single point, 2: trajectory with only entry point, 4: trajectory with only target point, 6: trajectory with entry and target point
R,G,B,A	8 bit unsigned	Color in RGBA
X1,Y1,Z1	32 bit float	Coordinate of the single point or entry point of the trajectory (which consists of an entry and a target point)
X2,Y2,Z2	32 bit float	Target point of a trajectory. If the trajectory has length 0, it is equal to the entry point. For single points the coordinates are 0,0,0
Diameter	32 bit float	Always 0 for single points, can be 0 for trajectories.
Owner image	char[20]	Id of the owner image/sliceset. Points from different slicesets can be sent if slicesets are fused.

* More than one item can be transmitted. The number is bodySize/itemSize.

Start / stop push

Currently there is no way to start or stop a pushing request. The message START_PUSH and STOP_PUSH shall be used for that purpose. The device name field shall contain the data type to be pushed. Everytime this data changes, new messages shall be sent until the pushing is stopped. The body of these message can contain data specific arguments.

An example is tracking data.

Tracking data

In version 1 of the protocol, transformation matrices can be transmitted. But there are some additional requirements.

• Specifing that something is not valid/visible anymore (could be done 0-matrix)
• Specifing which data comes from the same time / camera frame (can be done with the timestamp field of the header)
• Specifing the type of data, e.g. instrument, instrument without a direction, tracker, ... (could be done by a meta-data query)
• Sending all tracking data each frame, e.g. 5 instruments/trackers at 60 Hz result in 300 message per second, which is very much. This should be reduced.

All the points above can be handles with a new message, let's call it TRACKINGDATA:

Data	Type	Description
Name	char[20]	Name (=Id) of the instrument/tracker
Type	8 bit unsigned	1: tracker, 2: instrument with tip and handle, 3: instrument only with tip defined
Matrix	32 bit float	12 values like in TRANSFORM message

* All tracking data from one frame is included.
* Invisible/unavailable trackers/instruments are not included.
* Easy to develop. Sample pseudo code: while(true) { recv(trackingdata); updateView(trackingdata); }

This message cannot be queried with a regular GET message, but with START_PUSH and STOP_PUSH messages. The device name field consists of the string "TRACKINGDATA".

Usually the tracking data will be sent using the standard coordinate system, which is also used for POINTS, IMAGE, ... But this does only work after patient registration. Therefore the body of START_PUSH has an optional field for specifing the coordinate system "CAMERA". To switch back to the standard coordinate system, one has to send STOP_PUSH and afterwards START_PUSH without explicitly specifing the camera coordinate system.