VIRTUOS VDX file format

The Version 1.0 format is as follows:

voi <vname_1> type <vtype_1> #subvoi <nsubv_1> 
subvoi <subvname_1> 
#TransversalObjects <ntobj_1>

slice# <subv1_slice1> object {1|0} <xc> <yc> <dx> <dy> 0
#points <npnt> 
points <x1> <y1> <x2> <y2> ...
... <xn> <yn>

slice# <subv1_slice2> object ...
#points ... 
points ...

... more slices for subvoi 1

slice# <subv1_slicen> ...
#points ... 
points ...

#SagittalObjects <nsobj_1> 
#FrontalObjects  <nfobj_1> 



voi <vname_2> type <vtype_2> #subvoi <nsubv_2> 
subvoi <subvname_2> 
#TransversalObjects <ntobj_2>

slice# <subv2_slice1> object {1|0} <xc> <yc> <dx> <dy> 0
#points <npnt> 
points <x1> <y1> <x2> <y2> ...
... <xn> <yn>

slice# <subv2_slice2> object ...
#points ... 
points ...

... more slices for subvoi 2

slice# <subv2_slicen> ...
#points ... 
points ...

#SagittalObjects <nsobj_2> 
#FrontalObjects  <nfobj_2> 



... more voi's

voi voi_empty type 0 #subvoi 0

• vname_i (max. 80 characters)
  specifies the VOI name.
• vtype_i (integer value)
  specifies the VOI "type". The meaning of this number is pretty unclear, it should be within the range 1 to 10.
  This rule, however, is violated in the patient data sets of the GSI pilot project data. Moreover, no unique and unambiguous relation between VOI type and anatomical structure seems to exist. Vaguely:

  1    : target VOI,
  2    : seems to be related to target as well (or its surroundings),
  3    : chiasm, eyes, optical nerves
  4    : (mostly) chiasm
  5    : (mostly) eyes
  6    : optical nerve
  7    : brainstem
  8    : boost
  9,10 : ear related
  15   : myelon
  45   : darm, rectum
  67,68: hip joints
  99   : rand
  

  Because of this, the vtype_i are ignored in the TRiP98 context.
• nsubv_i (integer value)
  specifies the number of "subVOIs". In the TRiP98 context always nsubv_i=1.
• subvname_i (max. 80 characters)
  specifies the subVOI name, for nsubv_i=1 usually the same as vname_i.
• ntobj_i (integer value)
  specifies the number of "transversal objects" in the subVOI, i.e. the number of contours.
• nsobj_i and nfobj_i (integer values)
  specify the number of "sagittal" and "frontal" objects, but since these do not seem to be supported in V1.0, the respective keywords are ignored and nsobj_i=nfobj_i=0.
• subvnumi_slicej (integer value)
  specify the slice numbers within subVOI i. The numbers are within the range from 1 to slice_number, specified in the corresponding HED-file.
• object (integer value)
  describes the "object type" of the respective contour. It can take the values 1 (polygon points directly specified) or 0 (polygon points created from an ellipse with 41 break points). The object type determines how the following data are interpreted.
• xc, yc, dx, dy (integer values)
  specify coordinate values, in mm times 16.
  For ellipses (object 0) they specify the centre, width and height of the ellipse.
  For polygons (object 1) xc and yc represent the polygon's minimum x and y coordinates, respectively, and dx, dy represent the range. They are for information only and are ignored on read.
• <npnts> (integer value)
  For polygon objects only: number of points following.
• <xi,yi> (pairs of integer value)
  For polygon objects only: polygon point coordinates, in mm times 16.

The Version 2.0 format is as follows:

vdx_file_version   2.0
all_indices_zero_based
number_of_vois  <nvoi>

voi <vname_1>
   key 0
   type <vtype_1>

   contours
   reference_frame
   origin <orgx> <orgy> <orgz>
   point_on_x_axis 1.000 0.000 0.000
   point_on_y_axis 0.000 1.000 0.000
   point_on_z_axis 0.000 0.000 1.000

   number_of_slices <nslices_1>

   slice <slicenumber_1>
      slice_in_frame <slice_in_frame_1>
      thickness <thick_1>  reference  start_pos <start_1>  stop_pos <stop_1>
      number_of_contours <ncnt>

      contour <cnt_1>
         internal { false | true }
         number_of_points <npnt_1>
            <pntx> <pnty> <pntz>  0.000 0.000 0.000
            ...
      contour <cnt_k>
         internal false
         number_of_points <npnt_k>
             ...
      ...       
      
   slice <slicenumber_j>
      ...
voi <vname_i>
   key 0
   type <vtype_i>

   contours
   reference_frame
   origin <orgx> <orgy> <orgz>
   point_on_x_axis 1.000 0.000 0.000
   point_on_y_axis 0.000 1.000 0.000
   point_on_z_axis 0.000 0.000 1.000

   number_of_slices <nslices_i>
   ...
...

• <nvoi> (integer value)
  gives the number of VOI's in this file.
• <vname_i> (max. 999 characters)
  specifies the VOI name.
• <vtype_i> (integer value)
  specifies the VOI "type". Same as in VDX 1.0.
• <orgx>, <orgy>, <orgz> (floating point values)
  specifying the coordinate origin, in mm.
• <nslices_i> (integer value)
  Number of slices in this VOI.
• <slicenumber_j> (integer value)
  Running slice number. Has no real meaning since the order of slices is determined by <sliframe_j>.
• <sliframe_j>, <thickn_j> (floating point values)
  z-position and thickness of this slice, in mm.
  Usually <stop_j> = <start_j> + <thickn_j>, and <sliframe_j> should be in the middle.
• <ncnt> (integer value)
  Number of contours in this slices. Looks like more than one contour could be possible, however, TRiP98 doesn't support it yet.
• <cnt_k> (integer value)
  Running contour number (provided multi-contours are supported). Originally they started with 0, since June 2006 they start with 1. They have no real meaning.
• <npnt_k> (integer value)
  Number of polygon points following in this contour.
• <pntx>, <pnty>, <pntz> (floating point values)
  Polygon coordinates [mm] in this contour.
  <pntz> should be the same as <sliframe_j>.

An example is here.