image bound coordinate computation needs work

[adamsteer]

Maybe related to #18 - using lower camera pitch (making low oblique images), image bounds should be trapezoidal on almost-flat terrain (eg the yellow hand sketch area). Instead, they’re stretched away from the camera as shown in the image here. These were shot with an ANAFI thermal, for which ddb records CameraPitch, CameraRoll and cameraYaw just fine.

This image was made by a version of dronedb which removed the pitch cap here: https://github.com/uav4geo/DroneDB/blob/b6f2439c4d7fef5de53c8c5dd46f5fdcc50c5459/libs/entry.cpp#L229 - primarily to test projecting bounds of low oblique imagery.

In an ideal scenario the pitch limit would be far looser, and we’d compute trapezoids for image footprints.

[pierotofy]

:+1: I was actually wondering what would happen with this kind of imagery if the limit wasn't there xD glad you found out!

The problem is that the image footprint calculation assumes euclidean geometry (so no curvatures and infinite horizon). The trapezoid is more of a reflection of the camera frustum rather than the image footprint however (that would be a cool command to add though, like ddb geoproj --frustum?)

I think ideally we should place an absolute cap on the horizon distance (find averages for a sunny day) and limit the distance the image footprint can span.

[adamsteer]

:D I was expecting to see trapezoids. Years ago I struggled with a need to warp imagery onto a flat plane, results here (most of the rotation stuff done my a friend, I still don’t quite get it): https://github.com/adamsteer/python-opencv-image-projection/tree/master/rectify

…maybe someone who understands homographies better will be able to adapt it for a simple ‘footprint estimate'

…and yes, putting a limit on horizon would be useful - the computations for visible horizon assuming flatness seem pretty simple (https://www.boatsafe.com/calculate-distance-horizon/), maybe limit to some multiple of the distance between the camera centre and the nearest footprint points…(?)

[pierotofy]

Perhaps if you showed me an example of how the script differed in output I might be able to understand what you mean; the footprint must necessarily spawn infinity (and look like the one in the screenshot you attached), since the camera is pointing above horizon (or not?), unless we say "OK cool, but your camera doesn't really see past the horizon, because physics, earth curvature, etc. so trim your footprint not to be so far distant from the camera center".

A trapezoid would be the representation of a camera frustum?

[adamsteer]

The trapezoid is where the frustum intersects ‘ground’. Here’s a few of the images warped into regular drondb footprints, it is clearly finite - however, yes, imagery with very low pitch angles would need some ‘trim for sanity’ rules.

That python code intersects the frustum with a plane and does a projective transform on imagery. I’ll see if I can wake it up and get a result (or find an old figure which uses it). It might also be necessary to pretend a little bit about terrain...

[adamsteer]

*also, there’s no reason at all the footprint has to be a trapezoid, most of the time no two edges will be parallel.

‘roughly wedge shaped four sided polygon where the wedge is a little thinner nearer to the camera centre on flat terrain’?

[pierotofy]

I think I understand (thanks for the explanation)!

After calculating a sane/finite footprint you are warping the image to fit the plane. That's pretty swell (and the proper way to do it). This would be a cool addition.