coastal-imaging-research-network / cirn-quantitative-coastal-imaging-toolbox Goto Github PK

Hey Brittany,
This is an awesome toolbox! I have successfully used it to do extrinsic calibrations and rectifications of our camera on the outer Cape: https://usgs.gov/caco01. Everything is easily laid out, and it is easy for my summer students to follow the steps. I have only found two typos, and my only other comment is that it would be nice to indent the code...and that is so easy in Matlab: ctrl-a, ctrl-i.

The typos are in C_singleExtrinsicSolution.m:
line 155 - Shouldn't that be "World Y Axis"
line 165 - Now in Section 5

Great job! Chris

In G2_pixelInstruments, pixel instruments for xTransect and yTransect can be created. However, the y-coordinate and x-coordinate, respectively, for these must be a single constant value. For grids that have a localAngle rotation not aligned perfectly to the x/y grid or for beaches/coasts that aren't perfectly straight, this function cannot be utilized and one must go back to the old pixel toolbox way of creating pixel instruments.

example shown here for Isla Verde, Puerto Rico. Desired rotation angle causes beach/shoreline/coast not to be aligned with grid. Coast is slightly curved as well.

Anyone having issues with rotation matrices...this is a helpful document

https://danceswithcode.net/engineeringnotes/rotations_in_3d/rotations_in_3d_part1.html

Hi Brittany -
I recently tested out your CIRN-BOOTCAMP-TOOLBOX to see what it does.
So far I have only tried the "UAS Demo", but am looking forward to testing the fixed cam, and a few example sets of my own. I like it a lot. It must've been a tremendous amount of work!

Generally: It's super tidy! Logical, clear, well organized. Doesn't feel dense... light and fresh. Will be much easier for new members to grasp than the UAV-Toolbox.

Here are a few things I noticed with fresh eyes (having no idea what the repo contained):

1. Probably needs a simple 'road map for dummies', i.e. First, do A. Then do B, etc. Do we still use E if making a birthday cake rather than breakfast pancakes (see "bootcampToolboxIntroduction.pptx" for food reference)?

2. addpath to the repo code folder?

3. I like that you list required functions in each script... It might need to be updated, e.g. E_....m says 'none', but uses 'thresholdCenter.m'

4. imageRectifier: Neat visualization concept. Maybe add a note to explain how to change the resolution (idxdy)? Maybe add 'm' unit to X and Y stats and plots?

5. Initially I found E to be confusing (SCP), just because I wasn't sure where the SCPs were or how to select them (i.e. thresholding, square, feature detection?), BUT after clicking blindly through it became clear... And it's better than the old UAV-Toolbox version. I just didn't know what to do to start or what it was expecting. Could use some brief instructions.

6. PixelInsts - is it possible to input a line of xyz values, e.g. beach topo transect? - doesn't seem so.
   Does it save an r structure (like PIXtoolbox)? - yes - "pixInst". Will be good to recall this later.
   Can it automatically trim off pixels not in the oblique?
   Can it write pixellists for hotm?

Awesome!!

Hello all!

I am working on user feedback/questions at the moment and am seeing a lot of the same issues come up. I see this as a limitation of the toolbox literature...clearly I can do a better job in explaining some key aspects! I will work on incorporating this information into the Wiki... in the meantime I will write up some quick tips here to help anyone with issues!!

Many are getting errors in D_gridGenExampleRect. This can be due to a few things...

1. Incorrect Intrinsics Solution (which would cause #2 as well).
2. Incorrect Extrinsics Solution
3. Incorrect Grid Definition

Here are some tips to test each one

1. Incorrect Intrinsics Solution- VERY KEY WILL AFFECT ALL RESULTS. The user needs to do an intrinsic calibration for their own particular UAS in the same recording mode used for data collection. Do not use the file uasDemo_IO.mat or uasDemo_Calib_Results.mat. This is for the UAS used in the demo data. CIRN suggests using http://www.vision.caltech.edu/bouguetj/calib_doc/ for intrinsic calibration. One should take their UAS, film a checkerboard using the same recording mode, use A0_movie2frames to extract images, and follow the CalTech Example 1.

2. Incorrect Extrinsics Solution- Sometimes C_singleExtrinsicSolution will provide a solution that gives okay GCP errors, but does not make physical sense. The less number of GCPs you have spread across your image, the more likely this can happen. To check this, at the end of C, in the command prompt type extrinsics(1:3), this is your X,Y, and Z. Does this make sense, particularly the elevation? The Elevation Z can be a red flag for these solutions. Then type rad2deg(extrinsics(4:6)) this is the heading, pitch, and swing. Does this make sense? You should be able to guess the heading from your autopilot and roll should always be near 0. Erroneous solutions typically give large swings.

If these values are very off, I would check you are using the right intrinsics file. Then, I would utilize line 142 in C. This will 'fix' your initial guesses to be the final solutions. I would start with fixing swing and heading. This should provide more reasonable final solutions. You can then use these solutions as your initial guesses, unfix swing and heading, and the solver can find a more accurate solution as a result of the refined initial guess. It can be an iterative process.

3. If your intrinsics and extrinsics are sensible, it may be local grid definition. If you are getting a black screen... start with large grid extents (be sure to include both negative and positive directions). Reduce the resolution to cut down on processing time. This can help capture the image where ever it may be in the grid and you can fix your localOrigin and localAngle from there. Again, may be iterative.

Hope this helps!

Brittany

While investigating the relationship between Caltech and Metashape calibrations, it has come to my attention the coordinate systems defined in the manual may be misleading- particularly the relationship between XYZc and UV. What is shown in the manual is an undistorted relationship between the two- XYZc and UV have opposite X and Y directions. Actually, when calculating the distortion (distortUV, etc) we are using the Caltech model, which has XYZc and UV with the same directionality. This does not affect the results.... since the caltech calibrations are loaded as is, radial and tangential distortion are calculated correctly. However, it may trick expert users up who are trying to use other calibrations from other toolboxes, etc who look at the manual. I do not think this needs a change in the code- but rather clarification in the manual.

User mentioned the following Error.

Error using A0_movie2frames (line 103)
Frame index must be a numeric value greater than zero and less than or equal to the number of
frames in the file.

This will be investigated.

Hi I am getting the following error when I run script C and I am not certain what the possible reasons are.

Subscript indices must either be real positive integers or logicals.

Error in C_singleExtrinsicSolution (line 218)
x=[gcp(gcpInd).x];

Line 54 in xzy2DistUV: Is the second call to intrinsicsExtrinsics2P needed here?

Hi,

Is the output of G2 meet the requirements of what is needed for the runup tool?

When plotting pixel instruments with multiple cameras, there tends to be a wrapping effect that occurs, specifically for the grid. Attached is an image displaying the grid in a kind of 'loop'?

Some of the 'slashes' in our file directories are inconsistent. This is an issue for non-Windows users and may make the code error out.

Hi Brittany,

After some testing, I think that the Camera Calibrator App (included with Matlab's Computer Vision toolbox) is not only convenient (no clicking), but also seems to work better in some cases at resolving the lens model than caltech toolbox.

For people wanting to use that, it might be worthwhile including a translator (similar to your caltech2CIRN.m) from that output to the CIRN intrinsic variable (and maybe call it camcalibrator2CIRN.m).

Assuming that the user exports the "camera parameters variable" as params to workspace from the Camera Calibrator, then the translation to intrinsics is:

%% Conversion
intrinsics(1) = params.ImageSize(2);            % Number of pixel columns
intrinsics(2) = params.ImageSize(1);            % Number of pixel rows
intrinsics(3) = params.PrincipalPoint(1);         % U component of principal point  
intrinsics(4) = params.PrincipalPoint(2);          % V component of principal point
intrinsics(5) = params.FocalLength(1);         % U components of focal lengths (in pixels)
intrinsics(6) = params.FocalLength(2);         % V components of focal lengths (in pixels)
intrinsics(7) = params.RadialDistortion(1);         % Radial distortion coefficient
intrinsics(8) = params.RadialDistortion(2);         % Radial distortion coefficient
intrinsics(9) = params.RadialDistortion(3);         % Radial distortion coefficient
intrinsics(10) = params.TangentialDistortion(1);        % Tangential distortion coefficients
intrinsics(11) = params.TangentialDistortion(2);        % Tangential distortion coefficients

@JennaBrown-USGS

Happy 4th!

The user manual looks AWESOME!! Thanks for all of your hard work!

Quick question...my ocd is getting to me.... can we change the folder name to X_UserManualImages? Having the X there makes it clear it is not part of the code. If it is a huge pain to change (need to redo links etc)...no worries. I figured I would just ask :)

Thanks!

Brittany

Hi,

Just wanted to jump in and say that this toolbox is awesome! I am not familiar with MATLAB and this tutorial is very thorough, detailed, but not hard to follow.

Thanks Brittany!

Looks like this function has trouble doing multiple values at once...just works one at a time. Will fix.

Hi Brittany/Kate,

I've grown to appreciate the toolbox more, as I learn more!

I just wanted to point out there may be a typo on line 17 for P:

I thought it was supposed to be 3 x 4, as indicated in line 77 of the code?

Sharifa

Hi Brittany,

I've been going through this (wonderful) toolbox and stumbled on what I think to be an error in the variableExtriniscSolution code. The line in question is given below:

Let's take a simple 2 frame case where we want to find an extrinsic solution for a new frame by using a known (GCP-based) extrinsic solution from the previous (old) frame. According to the line above, the extrinsic solution for the new frame is found using the extrinsic solution from the old frame as an initial guess (👍), known flags (👍), lens calibration info (👍), the UVds of the stabilization points in the previous image (?), and the computed XYZs of the stabilization points (👍).

Shouldn't the extrinsic solution for the new frame be computed using the UVds of the stabilization points in the new frame, rather than in the old frame (i.e. using UVdn rather than UVdo)? As written, doesn't the line effectively compute a new solution for the old frame using the SCPs rather than GCPs? Many apologies if I am missing something fundamental here. Any guidance appreciated!

-Matt C

There is an error in the manual. Under Chapter 5: Intrinsics- it should read y=(V-Vo)/fy not y=(U-Uo)/fx.