1. Mapillary seems to be Losing It’s Marbles
2. Git Along, Little Dogies
   (speeding up renaming files)
3. I’m losing my Marbles because of Mapillary
4. A new record for Mapillary - 62 blurs on a street sign

(Be warned that today’s Diary is most whimsical)
(PS That picture above is linked to a “Family singalong”)

There is a house on Kenrick Road, Porchester Gardens, Nottingham that is called “Fool’s Jig”, and there is a link in the map to a picture lodged within Mapillary of that House-Name (below).

It is worth saying that that seems to be the only house in the world called “Fool’s Jig”. The name possibly refers to Will Kemp, one of the original Kings’ Men (the troupe that performed Shakespeare’s plays), the first to play Lear, and who was most famous for his nine-day jig from London to Norwich plus dying in poverty & neglect. There are also a dozen different interesting things in earlier Diaries about locations close to this house, including the way that the footpath Donkey Steps actually continues as footpaths across nearby houses and then used to run close to a neighbouring house and finally across to Porchester Road, but was stolen by that householder. However, none of that is the subject of this Diary.

How to Quickly arrange JPEGs within Directories

This is the command using exiftool to do the business:

exiftool '-FileName<CreateDate' -d '%Y-%m-%d_%H-%M-%S.jpg' .

The one-liner above will rewrite the names of all files within the directory (in this case it assumes that they are all JPEGs). An example resultant filename for the house-name above is 2016-09-28_10-46-07.jpg. It is also possible to rename all files and move them into directories, creating those directories as required (but not with this specific command).

EXIF Dates in Excruciating Detail

The exiftool uses xmp names in some instances, whilst the identify command-line tool from ImageMagick uses the standard EXIF field-names throughout (see exif r2.3 (PDF) (simple) or exif r2.3 (PDF) (full)):

$ identify -verbose 2016-09-28_10-46-07.jpg | fgrep -i datetime
    exif:DateTime: 2016:09:28 10:46:07
    exif:DateTimeDigitized: 2016:09:28 10:46:07
    exif:DateTimeOriginal: 2016:09:29 13:03:25

$ exiftool -a -G1 -s -time:all 2016-09-28_10-46-07.jpg    
[System]  FileModifyDate      : 2019:02:13 21:47:09+00:00    
[System]  FileAccessDate      : 2019:02:13 21:47:09+00:00    
[System]  FileInodeChangeDate : 2019:02:15 01:02:24+00:00    
[IFD0]    ModifyDate          : 2016:09:28 10:46:07    
[ExifIFD] DateTimeOriginal    : 2016:09:29 13:03:25    
[ExifIFD] CreateDate          : 2016:09:28 10:46:07

There are 3 date-times available for every OS:

1. cTime (metadata modification time)
   p9: DateTimeOriginal (EXIF IFD) = Date and time when the original data was generated
   FileInodeChangeDate - created by system & altered by system
   (same for identify + exiftool)
2. aTime (system access time)
   p9: DateTimeDigitized (amp:CreateDate) = The date and time when the image was stored as digital data
   FileAccessDate - certain system accesses will update aTime but leave mTime unchanged
   (different for identify + exiftool)
3. mTime (data modification time)
   p6: DateTime (xmp:ModifyDate) = Date and time when the file was last modified
   FileModifyDate - when file-data was last updated
   (different for identify + exiftool)

So what’s the point?

There are two things in this:

1. My Computer crashed & I lost some data due to a bad backup
2. The original mobile went weird on some shots

Mapillary offers a “Download unprocessed original” button for all photos that a user has uploaded. There is no Download all button, so it is one-by-one. Getting the filenames right was sending me up the wall. Then I was able to work out the command above & that was sorted.

Now look closely at the filetimes above and you will see that the DateTimeOriginal is different to all the others (and wrong). It was the same for a whole bunch of photos (iirc those were all shot with a mobile that eventually proved to be faulty). The bad metadata was causing problems with Mapillary, as it uses that field to tie all photos from a single user together. Whoops. I made sure to avoid that by using CreateDate myself.