I took some 360 images through a trimble Mobile Mapping system but unfortunately their coordinates and timestamps are not stored in the image EXIF data but in a separate CSV table. The data can be matched through the image names, but now I’m looking for a way to batch add all data in the image EXIF to upload them to Mapillary.
ExifTool supports CSV processing. You may have to transform the original CSV file a bit to make it digestable for ExifTool. Since CSV is pure text, it should be easy to do.
I am not sure that PNG supports Exif in a standardized way. Anyhow, Mapillary only supports JPEGs so far, which is also where Exif is native to the family of TIFF based file formats.
I’ve previously helped one of the Mapillary user for similar request. As @GITNE mentioned we supports JPEGs but not PNG but it should not be big problem to covert them to jpeg format.
Here are the steps to geotag your images with metadata which are in CSV file.
Prerequisites: Install ExifTool
The easiest way to install ExifTool on a Mac is via Homebrew.
Open your Terminal (Cmd + Space, type “Terminal”).
ExifTool requires a specific CSV format to match data to your images. You need to create a file named metadata.csv inside your image folder with specific headers.
The most important headers are:
SourceFile: The exact name of the image file (including .jpg).
GPSLatitude & GPSLongitude: Decimal coordinates.
GPSLatitudeRef & GPSLongitudeRef: ‘N’/‘S’ and ‘E’/‘W’ indicators.
DateTimeOriginal: The timestamp in YYYY:MM:DD HH:MM:SS format.
GPSImgDirection: GPSImgDirection is an EXIF metadata tag that records the compass bearing of the camera at the moment the photo was taken. While standard GPS coordinates (GPSLatitude and GPSLongitude) tell a map where you were standing, GPSImgDirection tells the map which way you were facing.
In your Terminal, navigate to the folder containing your images and the CSV: cd /path/to/your/image_folder (Tip: Type cd and drag the folder from Finder into the Terminal window to get the path automatically).
Run the following command: exiftool -csv=metadata.csv -overwrite_original .
What this does:
-csv=metadata.csv: Tells ExifTool to read the data from your CSV.
-overwrite_original: Prevents the creation of “original” backup files (remove this if you want to keep backups).
.: Tells the tool to process all images in the current directory.
Please make sure your timestamps are in the correct time zone, especially because DateTime* tags are time zone agnostic. Hence, you may want or need to add a OffsetTime* column to your CSV file. If the CSV file comes with GPS timestamps then ExifTool should read GPSDateStamp and GPSTimeStamp columns and you do not necessarily need to bother to add OffsetTime tags.
You have to pass ExifTool the path to the image files as the final parameter or the image files must be located in the same folder as the CSV file.
Please note that your CSV file lacks time zone data.
You have to append ExifTool’s install location path to the $PATH environment variable in order to be able to invoke it from any path location, or you have to prefix the command word with a path to its location on every invocation.
Thank you for the help, I’m getting closer. Unfortunately, still I’m getting errors.
C:\XXXX>exiftool -csv=metadata.csv -overwrite_original .
Invalid tag name 'SourceFile;GPSLatitude;GPSLatitudeRef;GPSLongitude;GPSLongitudeRef;DateTimeOriginal;GPSImgDirection' in CSV file
No SourceFile './pano_000011_000000.jpg' in imported CSV database
(full path: 'C:/XXXX/pano_000011_000000.jpg')
All files are in one directory. The images have exactly the name and path as written above. What am I doing wrong?
Reading error messages and TFM helps. ExifTool’s default CSV delimiter is ,. Pass -csvDelim ";" or replace all ; characters with , before you feed the CSV file to ExifTool. Man, think for yourself!
You do not read, not think for yourself, and you do not want to do any research yourself to solve your problems.
Sorry if I was asking stupid questions. I have basically no experience with these things (first time I ever opened the console). I can read obviously but I didn’t see anything that the programm needs ‘,’
So no need to be rude - but it’s working now, so thank you anyways
Looks good. However, the camera seems to be mounted backwards or stitching is done in such a way that the resulting image direction in the images views backwards (with respect to the direction of motion). Though, GPSImgDirection is correct but odd. Hence, things are not broken per se but you may want to give it a bit of consideration.
In equirectangluar projected images the image center is specified as the forwards view. As you can see in the flat image example above, the image center views backwards. If you can, you may want to try to either rotate the camera or make the stitching produce images with the image center viewing forwards.
Did you modify your timestamps or provide time zone data?
Unfortunately I don’t have much influence on the camera orientation as we just rent the mobile mapping car for a few projects and we can’t change the setup, but I could try to influence the stitching somehow next time. But as you said, it’s correct, just a little odd.
Considering the timestamps, I corrected them when preparing the CSV.
I see. Depending on you needs, you may want to consider investing in a GoPro MAX2 or similar camera. I am quite sure that you are going to have its cost recouped pretty quickly against renting a truck. Since the advent of miniaturized 8K image sensors, consumer grade 360° cameras have finally shaken off their toy status and have gained a minimum usable level of fidelity. In terms of image quality and resolution, they are not on par with that truck’s setup yet but they are coming close (for the price). Mapillary currently recommends the GoPro MAX2 specifically for mapping for good reasons. Mainly because it is one of the very few 360° cameras currently on the market that has a built‑in GPS receiver and provides an open well documented GPS data stream with a video stream (too). In other words, it has the smoothest workflow for mapping so far. You can go with other vendors and brands with higher resolutions. But, many of them lack a built‑in GPS receiver and they rely on a smartphone’s ability to reliably record GPX tracks. These device combos work but in reality they have a steep learning curve initially and later on are a pain in the rear to use for mapping because they require a lot of additional work in post-processing. So anyhow, give it a thought.
This image is also viewing backwards but has GPSImgDirection indicating forwards, which is broken by definition.
I can think of a few good reasons for which they have installed the camera facing backwards. Though, GPSImgDirection and the image center viewing directions should always both align. GPSImgDirection and the image center viewing backwards is generally okay. It is just a bit odd.
So, this is something you may need to look into more carefully.