Menu

Can't get geotag images to work on 1.7

lbayuk
2019-02-19
2019-05-06
  • lbayuk

    lbayuk - 2019-02-19

    I'm using Geotag Images to create waypoints on my map for photo locations, using a track I recorded at the same time. I've done this many times with previous Viking versions. I can't get it to work with Viking-1.7. There is no error message, but nothing happens - no waypoints are created. Using the same track, and the same photos, works fine with Viking-1.6.2 which I just rebuilt and loaded on another PC. I haven't dug deeper into this yet, but does anyone have any information? Has anyone successfully used Geotag Images on Viking-1.7?

     
  • lbayuk

    lbayuk - 2019-02-20

    I think I figured it out. There was a change to the way Viking processes EXIF date/times from image files. In 1.6.x it assumed they were in the local timezone, and in 1.7 it assumes they are in UTC. Because my image timestamps no longer matched the trackpoint times, the images were ignored for geotagging.

    (Aside: This seems to be one of those things that are impossible to get right. Whichever way you go - local time or UTC - you will be wrong sometimes, with some cameras. Blame equally the camera designers and the EXIF standard, who felt time zones were unnecessary.)

    The correct way to fix it is to put your timezone offset into the Geotag Images dialog: e.g. Image Timezone = -8:00 for US/California. That was unnecessary for me with Viking-1.6.x but is now needed. Fortunately, Viking stores this in your viking.ini preferences file so you only need to do it once. (Except for daylight saving time... Not sure, check back in about 3 weeks.)

    If you are affected by this and don't want to mess with the dialog value, you can revert ConvertToUnixTime() in viktrwlayer_geotag.c to the way it was in 1.6.x and leave the dialog Image Timezone value as +0:00. I know that fixes my geotag images problem but I don't know if it breaks anything else.

     
  • lbayuk

    lbayuk - 2019-04-23

    I just tried geotagging some images to a track recorded today, and they came out about 3 miles off. Reason: Daylight Saving Time since I last did this. Geotag image timezone was still set for Standard time, so my times were off by 1 hour. I'm not really happy about having to remember to change the Image Timezone field in the Geotag Images box twice a year to match daylight saving time. We really need an option that says: EXIF timestamps are local time - like Viking 1.6 did.

     
  • Rob Norris

    Rob Norris - 2019-04-28

    The EXIF times should be in UTC.

    However I note that EXIF 2.31 (2016) has added OffsetTime + OffsetTimeOriginal tags.
    http://www.cipa.jp/std/documents/e/DC-008-Translation-2016-E.pdf

    Does your images contain such tags? Using exiftool on the images should tell you.

    Viking ATM does not consider such OffsetTime fields in geotagging.

    I can also add an option in the geo tagging dialog to manually specify that the EXIF times are in local time if necessary.

     
  • lbayuk

    lbayuk - 2019-04-28

    I currently have 2 working cameras and an Android phone. Of the 2 cameras, the DSLR has no concept of time zone at all, and my compact camera does have a timezone setting, currently set to the correct value "New York, Toronto, Lima". My phone gets date, time, timezone, and if daylight saving time is in effect from the cell network.

    But all 3 of these devices timestamp their pictures using just local time in the EXIF tags. They set the tags Exif.Image.DateTime, Exif.Image. DateTimeOriginal, and Exif.Image.DateTimeDigitized to the current local time in the form "YYYY:MM:DD HH:MM:SS". No time offset is given, which according to the information from 'exiv2' is optional for the IPTC times: "HH:MM:SS optionally followed by -HH:MM or +HH:MM offset relative to UTC". I checked this with both exiftool and exiv2.

    None of these devices sets OffsetTime or OffsetTimeOriginal.

    So that's my experience and understanding. Whether cameras/phones know the timezone or not, they are displaying and time-stamping local time without timezone. Maybe there are cameras/phones out there that apply UTC times but haven't seen any.

     
  • Rob Norris

    Rob Norris - 2019-05-04

    My digital camera(s) have some 'World Location' + 'Travel' settings, but I've always ignored that and set the camera to UTC / GMT (which I felt was the recommended practise if going to be geotagging the images). Also it's handy as I live in the UK.

    Agreed, the mobile phone does seem to save image times as local time.
    I admit I haven't often tried to geotag the phone images, so not noticed an issue.

    So an option for 'Image Time is Local' is as you point out useful.

    However there still is problem that local timestamps don't include if daylight savings are in effect. So in the attempt to convert them back to UTC can go astray depending on the combination of the image time and the moment in time the action is performed.

    Thus previously IIRC, using the function mktime() which adjusts for local time, leads to wrong times (and thus wrong positions) at least when:
    1) The image is in DST (but values from timestamp don't say so) +
    2) The request is performed when DST has ended.

    There might be a way to get DST information automatically...

     
  • lbayuk

    lbayuk - 2019-05-05

    I considered setting camera clocks to UTC, but it doesn't work out well. Any photo viewer/editor I've used displays the time the photo was taken directly from the EXIF tag, without correcting, and I want to see the actual time the pictures were taken.

    Using mktime(), set tm.tm_isdst to -1 and the system is should figure out whether DST was in effect on the given date. The date of the request does not matter. So this should work fine.

    What probably doesn't work is if you travel to another timezone, adjust the clock in your camera (or your phone adjusts itself), take pictures, come back home and expect things to work automatically. But to me, that's an edge case...

     
  • Rob Norris

    Rob Norris - 2019-05-06

    Using mktime(), set tm.tm_isdst to -1 and the system is should figure out whether DST was in
    effect on the given date. The date of the request does not matter. So this should work fine.

    Yes this was how it used to work.

    I had a problem but simply worked around by adjusting the time offset and rerunning the geotag. I finally seemed to notice it only seemed to happen geotagging images in winter on summertime pictures, other times it was OK...
    Then noticed the code I'd based it on had been updated:
    https://github.com/freefoote/gpscorrelate/commit/0176129a5f1bb2d2180e0fd9f2830e13d7d6f043#diff-345fe4b7ce3e9fa2f3fc57bd23c1bc18

    However I can't recreate the circumstances that lead me to believe it would work sometimes and not others. It should have always been out of sync on my summertime images.

    Certainly if ones times are in UTC, using mktime() can adjust for a timezone factor when it doesn't need too.

    Now just trying to find the right wording for the TimeZone adjustment fields tooltip - since that's a bit misleading.

     
  • Rob Norris

    Rob Norris - 2019-05-06

    Geotag 'Image Time is Local' option is now in the latest code.

     

Log in to post a comment.

MongoDB Logo MongoDB