KateBrodie
commented
4 years ago @burritobrittany I completed my test of this branch - everything ran great except for A0_movie2frames.m. I like the new ability to do multiple cameras!
I'm running matlab 2019a, and my VideoReader output doesn't include NumFrames. You should be able to calculate it from v.Duration and v.FrameRate, which I do have! Can you update and re-submit?
A few other thoughts: -I might suggest increasing the resolution on the default grids for projection and at least the runup stack - just so the output looks better. -we might want to add some notes about bright vs. dark targets for stabilization and how one might change that -why are the default scp numbers 1,4,5,6?
burritobrittany
@SRHarrison @JennaBrown-USGS @mpalmsten @kkoetje Added some new features and fixes in this branch.
Added the function A0_movie2frames. This function takes a movie and given a specified frame rate will output images. I wanted to provide an example movie that we could use for the entire toolbox progression. I did not have access to the original UAV movie file. So, I took the first 10 frames and put them back together into a movie. Good news, this limits the file size and time it takes to export frames. Bad news...we can really only output at a max of 2Hz. This does not give our students much to explore. I renamed some folder structures to accommodate the new data. Directories specified in code were changed as a result as well.
Remade first frame of movie. I altered our first frame to have more information to help the user pick GCPs and SCPs. It also provides suggested radius and threshold values for SCPS. I also renamed the GCPS so just in order 1,23,4,5 (vs 1,2,3,6,7) and adjusted the gcp text file accordingly. I also switched a SCP, the one on the pier is not the closest target but the furthest. This actually works a lot better since there is no white water.
Tried to fix the 'wrapping' issue frequently seen in some rectifications due to distortion. In rectification we get three types of 'bad pixels:' 1) Outside of the image <0 or >NU,NV, 2) Negative camera Z value, and 3) wrapping due to tangential distortion. The first two I had originally placed in imageRectifier. Its difficult to put the third there too because it requires distortion calculations . Not wanting to repeat calculations in two different locations I put this correction in distortUV as well as 1) since they depend on intrinsic parameters. For tangential, I find the maximum theoretical values (at the corners) and remove any points where dx,dy tangential distortion is higher. This along with the NU,NV threshold is saved as a flag variable. I did not nan out the values to avoid errors in other code as well as error calculations. Similarly I did the 2) correction in XYZ2distUV, where it just adds onto the flag variable (1 good, 0 bad). ImageRectifier just applies this flag as a mask to get rid of bad pixels.
4.Added Multi-Camera functionality. I went back and forth on how this should go. I wanted to add this functionality without added a huge amount of functions or cluttering the code Ultimately, I altered the imageRectifier function so it could handle multiple images and IOEO in cell formats. If necessary it calls the cameraSeamBlend function for feathering if needed. This had a lot of back end ramifications- matrix sizes, formats, etc ...but i think the code is still understandable. To implement the multi-cam functionality, you really only need to add a for loop in G1,G2, and D1 and specify your inputs ieopath, impath, etc as a cell.
I did not do this for D1. Mostly because this a a very crucial step and I did not want to clutter up the code. Also, I provided new multicam demo data. Having very different grid parameters, I did not want to clutter that up as well. So I made it its own example function D2.
I did alter G1 and G2 to have a for loop. I then entered multi-cam parameters and commented them out. I instructed the user to uncomment them if they want to see the multi-cam example. Otherwise it would be two additional functions that are the same with the only difference being a for-loop and input parameters. I figured after seeing how the multi-cam work in D1, the user could handle this.
This format is up for discussion. One solution is using the Duck Argus data so everything shares the same grid and getting rid of D2. One could then compare the difference between fixed camera and UAS data. However, i do like the Hawaii Data shows a north-western facing coast example. Also, with six cameras I am not sure how much clutter that would remove.
The Hawaii data itself, its not the best set. The color balance is off between my cameras...very apparent. However-- I actually think it is helpful showing the feathering. Also, I was trying to reduce file size. So there are only 5 hourly snaps.... pixelInstruments do not look great. I may play around with this to get a better result. Right now I was just making sure the code is functional.
We will fight this beast like our ancestors...