GF2ARG - generates an ARG from a gf line set

NAME

gf2arg

SYNOPSIS

The (edited) synopsis generated by the optionsGM library is: Usage: gf2arg [options] arg_1 (null) [null] file prefix -a [0] ASCII o/p format -p [0] Uses polar relations -g [-1 -1] image size -R [-1.000] region-of-interest size -n [-1.000 -1.000] x & y s.d.s for feature measurements -x [-1] standard deviation of error in unknown x position -y [-1] standard deviation of error in unknown y position -r [-1] standard deviation of error in unknown rotation -s [0] standard deviation of error in unknown scale -help (1) [0] print out usage info

DESCRIPTION

gf2arg is a filter that takes as its input a set of points or line segments in gf format (gf(5)), and generates an Attributed Relational Graph (ARG). Support of the gf format is still limited - it can only handle points and lines, and does not understand the GeomStruct statement. However it does distinguish between oriented and non-oriented line segments (gf "orline" and "line" types respectively). The (binary) format of the ARG file is no longer documented because it keeps on changing. The functions that read and write it are put together in "arg.cc", so it is relatively easy to maintain them in step with each other. If a file prefix is specified, the gf set is read from <prefix>.gf and the ARG written to <prefix>.arg. If no file prefix is specified, stdin and stdout are used for i/o.

OPTIONS

<prefix> - input file is <prefix>.gf; output file is <prefix>.arg. Default is to use standard input and output. -a - generates an ASCII representation of the ARG, for diagnostic purposes. This format CANNOT be read by the matcher program. -c - position of centre of node j with respect to node i is included in binary relations in cartesian form; default is to include them in polar form. Cartesian for is recommended where line segments have bad longditudinal alignment (due say to line breakage). Polar form is recommended if allowance is being made for scaling errors. -e - creates angle values modulo 360 deg (default is 180 deg). for example, use -e for edge detector o/p, default for ridge detector o/p. -g <x_size> <y_size> - allows the user to include the size of the original image in the ARG that the features were extracted from. This information does not have to be that accurate; an adequate guess can usually be found on the basis of the maximum feature separation (which is used for the default). -R <ROI_size> - specifies feature separation beyond which relations will not be used. (-ve value indicates no limit.) -n <x_sd> <y_sd> - causes covariance matrices to be generated for all possible relations. <x_sd>, <y_sd> specify standard deviations for feature measurements. In the case of line segments, the x axis is assumed to be along the segment and the y axis perpendicular to it.

Transformation parameter ranges:

These parameters are the standard deviations of the errors in the parameters for the transformation between the scene and model spaces. Thus they indicate how much is known about this transformation. The transformation may consists of a translation, rotation and scaling. Each of these can be one of: known (s.d. = 0), part-known (s.d. indicates range of likely values) or not known at all (-ve value). A side effect of using these parameters (apart from -s) is that they often significantly reduce the amount of memory and computation time needed. These parameters must correspond between scene and model args. I.e. if a parameter is part-known in one it must be part-known in the other. Also, when the parameter(s) are present, it is assumed that the scene and model have been registered to within the available accuracy. A -ve value indicates that the parameter is not used. -x <posn_range>, -y <posn_range> - s.d. of relative translation error; default: not used -r <rot_range> - s.d. of relative orientation error (in degrees); default: not used for segment features, = 0 for point features -s <scale_range> - s.d. of relative scale error (expressed in terms of scale factor); default: = 0

SEE ALSO

matcher(1), arg(5), gf(5).

AUTHOR

Bill Christmas, University of Surrey, October 1994.
06-May-97. Automatically converted by man2html, written by G.Matas (g.matas@ee.surrey.ac.uk)