Public Lab Research note

  • 1

Copying GPS data capability added to photo monitoring plugin

by nedhorning |

The most frequent feature request for the photo monitoring plugin is to be able to copy GPS data from the original photo to the output NDVI or DVI image. This capability now exists in the most recent version of the plugin. The entire EXIF metadata set will be copied which includes GPS data (if they exist), time image was acquired, camera setting and over a hundred other pieces of information.

One caveat is that the EXIF metadata can only be copied from JPEG images at this time but that seems to be the most frequent case.

For dual-camera processing there is an option to select if the EXIF data should come from the visible or near-infrared camera.

Another related change is that I removed the option to specify the output image format. This was causing confusion so now color index images will be output in the JPEG format and the raw floating point (decimal) NDVI and DVI images will be output in the TIFF format. At this time only the JPEG images will have the EXIF metadata copied form the original photo.

The plugin and user guide are available on the Github site:

I also fixed a few bugs. If you have any issues running the plugin please let me know.

gps photomonitoring geo-tagging


Thanks Ned, this is a very nice capability to have added. As I demonstrated with this note: In my limited experience, Mapknitter places gps tagged images very nicely. In my test case, I basically just needed to rotate and scale. Granted it is within gps accuracy, so might need to translate a bit, but not much.

Yes Ned. This is a great added capability to maintain the georeferencing i work hard for. :-)

The RAW 16bit Tif dual image use capability seems to be broken now. It keeps telling me the image needs to be RGB. (?)

My Tifs were created in RawTherapee from Canon SX260 CHDK DNGs.

Also getting a Java Exifread error in the console now when trying to create the image lists. Is there a bug stomp in progress?

Thanks for your great work.

Hi Rich - I'll look into this. I think I know what the problem is but the fix isn't easy. Dealing with the EXIF data has been a bit of a nightmare. The EXIF read error seems unrelated but I'll look into that too. For what it's worth a colleague of mine is working on a Python version and that will hopefully be easier to modify and maintain. He's also a very good programmer and I am definitely not. I'm not sure what that will be available but I'll post a notice as a research note.

If possible can you send me some test images - maybe 2 pairs. You can contact me at I can't recreate the EXIF problem with my images.

I made some progress with the plugin. I think I fixed the error related to creating the image pair list and RGB image error. I'm still working on copying the GPS metadata to the output JPEG image. If possible can you send me some test images - maybe 2 pairs. You can contact me at

Thanks for your work on the plugin Ned. I've been experimenting with it to create an NDVI mosaic from 148 aerial images taken with a custom dual-camera setup. My first attempt was to create the NDVI image for each image pair, and then stitch the NDVI images into a mosaic. That didn't work very well because the stitching software (Autopano Giga) seemed to be put off by slightly different NDVI values for the same scene across multiple images. Lately though I've tried creating a mosaic for RGB, and a mosaic for NIR, and then using your plugin to create an NDVI image from the two. That worked a lot better, though the black around the edges of the mosaic created an unexpected effect of a pink hash pattern in the NDVI image.




I'm wondering whether the black edges also confuse the affine transformation in bUnwarpJ. Do you think I should replace the black with a more neutral colour before feeding it into the plugin?

Here's my log.txt: PARAMETER SETTINGS: Use backup registration method if primary fails? true Select primary registration method: SIFT/Landmark correspondences Select secondary registration method: bUnwarpJ Select transformation type if using SIFT: Affine Number of tries for SIFT to find correspondence points: 1 Method to improve SIFT point selection: none Select index type for calculation: NDVI: (NIR-Vis)/(NIR+Vis)

Output NRG image? false Clip images? true Output clipped visible image? false Output Color Index image? true Minimum Index value for scaling color Index image: -1.0 Maximum Index value for scaling color Index image: 1.0 Output floating point Index image? false Stretch the visible band before creating Index? true Stretch the NIR band before creating Index? true Saturation value for stretch: 2.0 Channel from visible image to use for Red band to create Index: 1 Channel from IR image to use for IR band to create Index: 1 Select output color table for color Index image: NDVI_VGYRM.lut

PHOTO PAIR PROCESSING SETTINGS: Images image_1440467454-rgb_image_1440467896-rgb-145-images.jpg and image_1440467454-nir_image_1440467896-nir-145-images.jpg registered using SIFT and landmark correspondences with Affine transformation

That pink hash is pretty cool. The hash pattern is present in the black background of both the NIR and VIS mosaics. So if you could change that to a solid field, the pattern would probably not be present in the NDVI image.

A bigger problem seems to be that the NIR and VIS mosaics, which were apparently made without ground control points, do not match perfectly. When the plugin overlays them, it does not transform them enough to produce a very good alignment. From the offset margins in the top half of the NDVI image it appears that the NDVI values are being computed from NIR and VIS values that are in some places many (10-20?) meters apart. That would greatly reduce the usefulness of the NDVI values.

This is an important issue that many people will encounter. Maybe a solution is possible. The NDVI values require only a single channel in an image file. So a standard image file has two additional channels that are not being used. When the individual photos (NIR and VIS) are aligned and used to produce an NDVI image, that output image could include one channel for NDVI and two of the channels from one of the original photos (e.g., VIS). Then those NDVI images could be stitched into a mosaic using the two VIS channels. The NDVI channel would be included in the stitched mosaic and could be displayed. This might require a stitching program that allows you to select which channels to use for stitching, although maybe stitching would work well using the entire hybrid image. The VIS channels would include the best matching information, and maybe the SIFT algorithm would rely on that and just bring the NDVI channel along for the ride. In the mosaic there would be blending of the NDVI values where images overlapped, but that might be exactly what you want.

So the first thing to try might be to modify the Fiji plugin so it output an NDVI image with a grayscale channel for NDVI and also two VIS channels (or a four-channel TIFF, but that might complicate the next step). Then see if stitching programs can stitch them together into a mosaic. Then figure out how to put the mosaic back into Fiji and display the single NDVI channel with a color lut.


There have been a few requests over the years to add the capability of outputting different numbers of bands along the lines of what Chris mentioned in the FIJI plugin but it's a bit of a pain. There is a chance that a new, Python based, program will be developed that will have some options to make it easier to create NDVI mosaics of several images. For what it's worth, most remote sensing and GIS software has options to create multiband images to you can take the output from the FIJI plugin and input that into the GIS or remote sensing software to create images with whatever bands you like. You can also use ImageJ/FIJI for that but you are (more or less) constrained to outputting 3-band images.

I appreciate your thoughts Chris and Ned.

For interest, I obtained a much better result (i.e. better registration) when I cropped the RGB and NIR mosaics first, and then ran them through the NDVI processing. Perhaps the ragged edges gave the affine transformation in bUnwarpJ too much to think about - it did a better job once the mosaics were cropped.


You must be logged in to comment.