Difference between revisions of "OpenIGTLink/Discussion/NewCommands"

From NAMIC Wiki
Jump to: navigation, search
m
m
Line 14: Line 14:
 
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.
 
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.
  
= Errors in GET-messages =
+
= GET messages =
  
 
Get messages are not well defined yet. The following things should be fixed:
 
Get messages are not well defined yet. The following things should be fixed:

Revision as of 11:19, 7 April 2010

Home < OpenIGTLink < Discussion < NewCommands

Common get list ?

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 it can they 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

START_PUSH + STOP_PUSH

Tracking data

TRACKINGDATA