Working with LiVT: file size limits and performance

It’s been a bit more than half a year since I first published LiVT on Sourceforge. Since then, I have been able to add a few more algorithms, but there are still a few bugs waiting to be fixed.

All in all, feedback so far has been positive, but I am still hoping that someone will offer help to improve the project. One thing that has been mentioned repeadedly is the need to know the limits of the software regarding maximum file sizes.

Another relevant issue is the performance of LiVT, i.e. the time needed per unit area. This differs greatly from algorithm to algorithm. Furthermore, different settings in each algorithm will strongly influence processing times. Therefore, I have run all tests using the default settings with the exception of Cumulative Visibility where I used an angular resolution of 10° (instead of the 1° default). When changing processing parameters, processing times can change proportionally (e.g. for maximum radius or no. of direction in the radial Sky-View Factor algorithm), quadratic (e.g. for filter radius in the filter algorithms) or even faster (e.g. for the number of scales in Exaggerated Relief or Multi-Scale Integral Invariants). The test data set had a resolution of 1 m. Note that for the same total area, file size and processing times quadruple when resolution is doubled.

These are the results of the tests I have run:

Algorithm

maximum DTM file size

[million pixels]

performance (Intel Xeon 3.2 GHz, 64 bit)

[km2/min]

Filter (Laplacian of Gaussian)

132

30

Shaded Relief

30

15

Exaggerated Relief

30

 0.48

Sky-View Factor

131

0.96

Trend Removal

132

5.22

Local Relief Model

56

0.09

Local Dominance

90

2.22

Cumulative Visibility

90

0.25

Accessibility

132

1.45

Multi-Scale Integral Invariants

144

0.57

Openness

132

1.92

These tests were run on an 64 bit Intel Xeon at 3.2 GHz under Windows Vista. As a single instance of LiVT uses only one processor core anyway, the number of processors and cores does not play a role. Running the performance tests on other computers showed that 64 bit has some advantage over a 32 bit system: On a slightly faster clocked 32 bit AMD Phenom at 3.4 GHz (also under Windows Vista), performance was on average 87% of that on the 64 bit computer. Finally, just for fun I also tested a 32 bit Intel Atom processor (on a four or five year old EeePC) at 1.6 GHz under Windows XP. On that computer, performance was on average 18% of that on the 64 bit machine.

UAVphoto – a simple calculation tool for aerial photography

I have to admit that I am sometimes a bit lazy. Rather than solving a problem once and working with the solution, in some cases I keep twiddling with the same problem again and again. Calculating things like viewing angles, ground resolution, motion blur or image overlap for aerial photography is a case in point. There must be a dozen or so spreadsheet files on my various computers which I used to do such calculations. I kept re-inventing the wheel again and again for myself and when others asked me for help.

UAVphoto_1.0.0.0_screenshot

Now I finally got around writing a small piece of software for this specific task. It is a simple tool that allows to calculate parameters like ground pixel size, motion blur and sequential image overlap from UAV flight parameters (velocity and altitude) and camera parameters (focal length, shutter time, image interval etc.). Calculation assumes a vertical camera view for simplicity. Image y dimensions are those in flight direction, image x dimensions are those perpendicular to flight direction. Default camera values are for Canon G12 at the wide angle limit. Five to six seconds is the approximate minimum image interval using a CHDK interval script. In continous shooting mode, a minimum interval of approximately one second can be achieved.

Now that I created this tool, why not share it? UAVphoto is published under the GNU General Public License and can be downloaded from Sourceforge.