You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would work for any underwater images above the Afar Depression, but I just realized the Dead Sea is lower. I've changed the proposed value. So, anyone doing underwater images on the Dead Sea will be out of luck, or need to change their version.
This also applies to areas where the geoid is well below the ellipsoid, which is an even longer list than the above. Much of the coast of Tanzania is below sea level on the elipsoid, but the India Ocean hasn't read the map, so folks stay dry enough.
Is there any way to set a false plane for this purpose? Isn't what matters the relative difference between the camera and the ground and not the absolute position?
AFAIK, this is done during pair_selection; if my memory serves me right, this is to project a "representative point" of where the camera(scene) is being captured. It shouldn't affect things like actual 3D bundle constraints, although it may discard pair candidates. You can try to disable this by using the config matching_vlad_gps_distance=-1 (if using vlad)
That said, your use case seems rather unique and most definitely not contemplated. I am not sure it will work that well out of the box, definitely something interesting to look at if you share some datasets.
@sbonaime -- do you have an example dataset you can share for testing?
Hi,
I have images but Altitude is not is the exif. It was recorded using a kind of sub gps. So I created a geo.txt file which is like that :
EPSG:4326
20210430T214436.000Z.jpg 45.4130459270 -12.8241450307 -1526.27 144.92 0.00 0.00
20210430T214439.000Z.jpg 45.4130443807 -12.8241464119 -1526.18 144.47 0.00 0.00
20210430T214442.000Z.jpg 45.4130396481 -12.8241511723 -1526.13 144.35 0.00 0.00
20210430T214445.000Z.jpg 45.4130347807 -12.8241543977 -1526.05 143.85 0.00 0.00
20210430T214448.000Z.jpg 45.4130314280 -12.8241571291 -1525.93 144.47 0.00 0.00
20210430T214451.000Z.jpg 45.4130286187 -12.8241588002 -1525.86 143.80 0.00 0.00
20210430T214454.000Z.jpg 45.4130271377 -12.8241611745 -1525.78 144.63 0.00 0.00
Activity
smathermather commentedon May 22, 2024
Proposed pull request to address, keeping it simple: if Z is below Lake Assal, it's probably invalid, but treat as valid otherwise:
#32
sbonaime commentedon May 22, 2024
@smathermather I am now using ODM for underwater data ... so maybe we can have an option for real underwater images ?
smathermather commentedon May 22, 2024
This would work for any underwater images above the Afar Depression, but I just realized the Dead Sea is lower. I've changed the proposed value. So, anyone doing underwater images on the Dead Sea will be out of luck, or need to change their version.
This also applies to areas where the geoid is well below the ellipsoid, which is an even longer list than the above. Much of the coast of Tanzania is below sea level on the elipsoid, but the India Ocean hasn't read the map, so folks stay dry enough.
smathermather commentedon May 22, 2024
@sbonaime -- do you have an example dataset you can share for testing?
disarticulate commentedon Aug 14, 2025
Is there any way to set a false plane for this purpose? Isn't what matters the relative difference between the camera and the ground and not the absolute position?
DodgySpaniard commentedon Aug 5, 2026
AFAIK, this is done during pair_selection; if my memory serves me right, this is to project a "representative point" of where the camera(scene) is being captured. It shouldn't affect things like actual 3D bundle constraints, although it may discard pair candidates. You can try to disable this by using the config matching_vlad_gps_distance=-1 (if using vlad)
That said, your use case seems rather unique and most definitely not contemplated. I am not sure it will work that well out of the box, definitely something interesting to look at if you share some datasets.
sbonaime commentedon Aug 10, 2026
Hi,
I have images but Altitude is not is the exif. It was recorded using a kind of sub gps. So I created a geo.txt file which is like that :
EPSG:4326
20210430T214436.000Z.jpg 45.4130459270 -12.8241450307 -1526.27 144.92 0.00 0.00
20210430T214439.000Z.jpg 45.4130443807 -12.8241464119 -1526.18 144.47 0.00 0.00
20210430T214442.000Z.jpg 45.4130396481 -12.8241511723 -1526.13 144.35 0.00 0.00
20210430T214445.000Z.jpg 45.4130347807 -12.8241543977 -1526.05 143.85 0.00 0.00
20210430T214448.000Z.jpg 45.4130314280 -12.8241571291 -1525.93 144.47 0.00 0.00
20210430T214451.000Z.jpg 45.4130286187 -12.8241588002 -1525.86 143.80 0.00 0.00
20210430T214454.000Z.jpg 45.4130271377 -12.8241611745 -1525.78 144.63 0.00 0.00
Fix MSVC's C4244 implicit conversion warnings (#30)
Fix MSVC's C4244 implicit conversion warnings (#30)