3. Script Descriptions: D_gridGenExampleRect

• D_gridGenExampleRect

  • Description:

  This function generates grids for rectification in both world global and world local rotated coordinate systems. The function rectifies a single oblique image into rectified imagery for a one or multiple cameras. The user will load an intrinsic and extrinsics solution (IOEO) for each camera via input files. The user will specify the resolution and limits of the rectified grid and local rotation parameters for a local coordinate system. The user can enter the grid parameters in local or world coordinates; the function will make a corresponding grid encompassing the other system. The function will produce figures and save .png images of the georectified imagery in both coordinate systems. In addition, the prescribed grids will be saved as well in a mat file.

  The user input of the code is prescribed for UASDemoData. However, one can uncomment lines in Section 4 for the FixedMultiCamDemoData.

  This function is to be run fourth in the progression to evaluate camera extrinsic solutions and georectification grids. For UAS it should be run on the first image used for camera IOEO calibration. For fixed camera stations it can be ran on any imagery with the corresponding IOEO.

  • Input:

  Input is entered by user into the script in Sections 1-4.

  Section 1: Saving + Output Information

  Variable	Description
  oname	Output string for the basename for the example rectified images to be saved under.
  odir	Output filepath where the rectification grid mat file will be saved.
  gname	String for the basename for the rectification grid.
  teachingMode	A flag to display intermediate steps in rectification, i.e showing transformation of XYZ points to Image UVd points. It is implemented in the sub-function imageRectification. For demo purposes, it should =1 to show intermediate steps. Otherwise set to 0 if not desired.

  Section 2: Loading Information

Variable	Description
imagePath	Filepath of the image you would like rectified. This should be the same image used in B_gcpSelection and C_singleExtrinsicSolution (imagePath) if you are doing a UAS collect or a moving camera. For a fixed camera, it can be any image where intrinsics and extrinsics are valid.
ioeopath	Filepath of the saved CIRN IOEO calibration results produced by C_singleExtrinsicSolution. If not produced by C, minimum variables are listed below.
	intrinsics	A [1x11] vector describing the focal lengths and distortion of the camera/lens combination. Distortion coefficients are defined by [3] and defined in Section 6.
	extrinsics	A [1x6] vector describing the camera pose and position in WORLD coordinates (whatever coordinate system GCPs were entered in). Extrinsic values are defined in Section 6 along with coordinate systems.
NOTE: For multiple cameras, these values are entered as cell entries for each camera. The extrinsics for each camera should all be in the same world coordinate system. It is up to the user to make sure the entries for both variables correspond to the same cameras.Even for a single camera, both impath and ioeopath need to be entered as cell functions with one entry.

Section 3: Rectification Information

Variable	Description
worldCoord	String of description of the World coordinate system for your own records. The world coordinate system of these should be the same as the IOEO specified in C_singleExtrinsicSolution (gpsCoord, camSolutionMeta.worldCoordSys).
Coordinate System Info: Enter the origin and angle if you would prefer rectified output to be in a local rotated right hand coordinate system. CIRN local coordinate systems typically have the new local X pointed positive offshore, Y oriented alongshore, and the origin onshore of the shoreline. If fields are entered, user will still be able to rectify in both local and world coordinates. Note, if user already specified their world coordinates as a local system, or do not desire a rotation, set localOrigin and localAngle to [0,0] and 0. More description of coordinate systems is in Section 6.
localOrigin	Origin of new local coordinate system in world coordinates. should be in the same coordinate system of GCPs (worldCoord).
LocalAngle	relative angle between the new (local) X axis and old (World) X axis, positive counter-clockwise from the old (world) X. Units are degrees.
localFlagInput	Flag if you would like to INPUT your grid in rotated local coordinates. 1=local coordinates, 0= world coordinates. The function will still rectify both coordinate systems regardless of localFlagInput value. LocalFlagInput only dictates the coordinate system of the input and which direction the rotation will occur. If localOrigin and localAngle =0; this value is irrelevant.
Grid Specifications:
ixlim	A [ 2 x1] vector specifying the x or y limits of the rectification grid.Units should be consistent with worldCoord, coordinate system dependent on localFlagInput.
iylim
idxdy	X and Y resolution of grid in units consistent with worldCoord
iz	The elevation you would like your gridrectified as. Typically, CIRN specifies an constant elevation across the entire XY grid consistent with the corresponding tidal level the world coordinate system. For more accurate results a spatially variable elevation grid should be entered if available. However, this code is not designed for that. If you would like to enter a spatially variable elevation, say from SFM along with tidal elevation, enter your grid as iZ. It is up to the user to make sure it is same size as iX and iY. Spatially variable Z values are more significant for run up calculations than for current or bathymetric inversion calculations. It can also affect image rectifications if concerned with topography representation. What does alter bathymetric inversion, surface current, and run-up calculations is a temporally variable z elevation. So make sure the elevation value corresponds to the correct tidal value in time and location. For short UAS collects, we can assume the elevation is relatively constant during the collect. However for fixed stations we would need a variable z in time. This function is designed for rectification of a single frame, so z is considered constant in time. Value should be entered in the World Coordinate system and units.

Section 4: Multi-Camera Demo

Uncomment this section for the multi-camera demo. impath and ioeopath should be entered as cells, with each entry representing a different camera. It is up to the user to ensure that entries between the two variables correspond. Extrinsics between all cameras should be in the same World Coordinate System. Note that no new grid is specified in this example since the data for the multi-cameras cover the same region as the UAV data; hence, the cameras and images are all rectified to the same gird.

• Output:

A .mat file saved as GRID_gname.mat in odir. Will contain following variables. Variables left blank are the same as what is input by user above.

Variable	Description
X	NxM grids in World coordinates where N is the number of rows (direction of varying Y) and M is the number of columns (direction of varying X).
Y
Z
worldCoord
localAngle
localOrigin
localX	NxM grids in rotated Local coordinates (according to localAngle and localOrigin) where N is the number of rows (direction of varying Y) and M is the number of columns (direction of varying X).
localY
localZ

Example georectified images of those specified in impath and using specified grid parameters saved as oname_World.png and oname_Local.png in odir.

Depending on teachingMode input, two figures for each camera showing complete georectification as well as XYZ grid points reprojected into UVd image space for both world and local coordinates. Examples shown below in Figure 5.

• Required Core Sub-Functions:

  • imageRectification
  • xyz2DistUV
  • cameraSeamBlend
  • intrinsicsExtrinsics2P
  • distortUV
  • localTransformExtrinsics
  • localTransformPoints
  • localTrasnfromEquiGrid



Figure 5: Example figure output for D_gridGenExampleRect for uasDemoData for World (Top) and Local (Bottom) coordinates.