Orthophotos from orthophotos?

An increasing desired use case for OpenDroneMap is to use it for non-drone maps. For example:

  • I have a bucket of scanned images from the 1950’s. I want to make them into a mosaic. I have the geographic center for each image. Can I process these in OpenDroneMap?
  • I have a bucket of individually orthorectified images from a sensor like from the Wildfire Airborne Sensor Program (WASP). I’d like to mosaic them into one image. Can I process these in OpenDroneMap?

The answer is unknown for the first question, and I’m looking forward to testing. For the second question, I have done some testing with great success.

The WASP sensor, as flown for the mission I’m testing outputs a whole bucket of individually orthorectified imagery.

Image of aerials with lines showing boundaries of overlapping independently orthorectified imagery.
Image of aerials with lines showing boundaries of overlapping independently orthorectified imagery.

The problem that we encounter is both radiometric inconsistencies between images and geometric offsets.

offsets
Screen shot showing radiometric inconsistencies and geometric offsets.

Fortunately, OpenDroneMap is good at dealing with both. The questions for this dataset simply were — is there enough overlap to allow ODM to do its magic && and does it create usable output?

Looking at overlap was promising:

overlap3
Image showing the high level of overlap in overlapping image footprints.

The best thing to next is to try. One problem. ODM doesn’t read GeoTiffs. Oops. Two problems — ODM assumes that your data has exif headers describing the location of the camera when the image was taken.

The first problem is easy. If we want jpegs, we might run something like the following:

for f in *.tif; do

gdal_translate -of JPEG -co QUALITY=100 -co worldfile=yes -scale 0 1024 0 255 $f $f.jpg

; done

The second problem is a little trickier. We can extract info from our new jpegs pretty easily with gdal:

gdalinfo orthoVNIR2549_flatfield.tif.jpg

Resulting in something like the following:

Driver: JPEG/JPEG JFIF

Files: orthoVNIR2549_flatfield.tif.jpg

orthoVNIR2549_flatfield.tif.jpg.aux.xml

orthoVNIR2549_flatfield.tif.wld

Size is 3233, 4303

Coordinate System is:

GEOGCS[“WGS 84”,

DATUM[“WGS_1984”,

SPHEROID[“WGS 84”,6378137,298.2572229328696,

AUTHORITY[“EPSG”,”7030″]],

AUTHORITY[“EPSG”,”6326″]],

PRIMEM[“Greenwich”,0],

UNIT[“degree”,0.0174532925199433],

AUTHORITY[“EPSG”,”4326″]]

Origin = (-72.222122858200009,18.545027305599998)

Pixel Size = (0.000001126600000,-0.000001126600000)

Metadata:

AREA_OR_POINT=Point

EXIF_GPSLatitude=(18) (32) (33.3722)

EXIF_GPSLatitudeRef=N

EXIF_GPSLongitude=(72) (13) (13.0861)

EXIF_GPSLongitudeRef=W

EXIF_GPSVersionID=0x2 0x3 00 00

EXIF_ResolutionUnit=1

EXIF_XResolution=(1)

EXIF_YCbCrPositioning=1

EXIF_YResolution=(1)

Image Structure Metadata:

COMPRESSION=JPEG

INTERLEAVE=PIXEL

SOURCE_COLOR_SPACE=YCbCr

Corner Coordinates:

Upper Left  ( -72.2221229,  18.5450273) ( 72d13’19.64″W, 18d32’42.10″N)

Lower Left  ( -72.2221229,  18.5401795) ( 72d13’19.64″W, 18d32’24.65″N)

Upper Right ( -72.2184806,  18.5450273) ( 72d13′ 6.53″W, 18d32’42.10″N)

Lower Right ( -72.2184806,  18.5401795) ( 72d13′ 6.53″W, 18d32’24.65″N)

Center      ( -72.2203017,  18.5426034) ( 72d13’13.09″W, 18d32’33.37″N)

Band 1 Block=3233×1 Type=Byte, ColorInterp=Red

Overviews: 1617×2152, 809×1076, 405×538

Image Structure Metadata:

COMPRESSION=JPEG

Band 2 Block=3233×1 Type=Byte, ColorInterp=Green

Overviews: 1617×2152, 809×1076, 405×538

Image Structure Metadata:

COMPRESSION=JPEG

Band 3 Block=3233×1 Type=Byte, ColorInterp=Blue

Overviews: 1617×2152, 809×1076, 405×538

Image Structure Metadata:

COMPRESSION=JPEG

From this we can just extract what we need from the image center info:

gdalinfo orthoVNIR2549_flatfield.tif.jpg | grep Center

Which results in the following:

Center      ( -72.2203017,  18.5426034) ( 72d13’13.09″W, 18d32’33.37″N)

Ok, this will require a little filtering to extract what we need. Then we’ll use exiftool to write it back to the file as follows:

Voila! Now we can process in OpenDroneMap. Now to find an older historical dataset to attempt this on.

output1
OpenDroneMap derived mosaic of input orthophotos with remaining image boundaries to process in the background.

2 thoughts on “Orthophotos from orthophotos?

  1. Hi Stephen,

    I came across your blog while doing research on OpenDroneMap in an attempt to learn more about its pipeline and capabilities.

    I, along with a few of my colleagues, are looking for some help with OpenDroneMap – we’re looking to tune parts of it, and are looking for someone with deep expertise around how it all works as well as GIS in general to provide guidance and ensure that we are pursuing the right approaches.

    While we’ve learned a lot just from reading through your posts, we’re still not certain that the amount we have gleaned thus far will be sufficient for us to succeed alone.

    Are you open to providing support and/or consulting for something like this?

    If so, happy to provide more details on what exactly we are trying to accomplish.

    Thanks,
    James

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s