What time is used to place a file onto a GPX track in Map panel?

[ubacher]

I have a jpg file which I can place on a gpx track in the map panel - the corresponding NEF file does not show!

So I started to look at time stamps. Help says Imatch looks at EXIF DateTime created. I took VarToy to search for this
tag and could not find it. Should it be DateTimeOriginal or CreateDate?

The fall-back mentioned in the help file is EXIF DateTime Digitized - which I also can not find with VarToy.

Because of the many time stamps in a file I need to know which one is used so I can find out why the jpf file displays and the NEF does not.

[Mario]

I don't understand.
What do you mean by "place a JPG file on a GPX track"?
Do you load a track log? Do you use the feature to display files along a track? Does the NEF have GPS data?

[ubacher]

I load a GPX track, select a NEF file and select the option Preview selected files on track

The file does not show up. (The corresponding JPG file was found and I got to assign GPS data to it.)

Must lie on a bad/missing date in the NEF file?

[Mario]

The track log import locates the currently selected files by comparing the track timestamps with the EXIF timestamps of these files.
Check the EXIF timestamps of the NEF file and compare them with the JPEG file. Any differences?

[ubacher]

Check the EXIF timestamps of the NEF file and compare them with the JPEG file.

I did. That's when I noticed that there is no EXIF DateTime Created - the one mentioned in the MAP panel help file.
So it must be one of the other datetime fields. Thus my question in the initial post.

My checks seem to exclude that it is an exif date/time field that is being used (I checked their presence in the exiftool output)

[Mario]

IMatch uses several EXIF and other timestamps to produce the global File DateTime used by IMatch everywhere, from the file window to the timeline to the Map Panel.
How IMatch uses Date and Time Information

When mapping tracks, the map panel uses the createdate and the datecreated as the fall-back. This allows it to use potentially existing time-zone data as recorded by the device for better precision.
Make sure that the NEF file has valid information in the two date & time fields shown in the Metadata Panel (Default layout). Then mapping will work, the timeline will work and all date-related features as well.

If your camera fails for some obscure reason to fill these two tags or fills only one, you a metadata template or the TimeWiz or the Metadata Mechanic to copy the date from the filled tag into the empty tag.
Or just to it manually in the Metadata Panel via copy & paste if only a few of your files are affected.

[ubacher]

I now found 2 NEF files, one maps the other does not. (Associated jpgs do map!)

I am stumped.
I will mail the two files plus the track file to support.
(Time zone offset = -1)

[Mario]

I will mail the two files plus the track file to support.

I have currently almost 50 "needs time to check" support cases in my inbox...

How important is this for you?
It will cost me at least 20 minutes, maybe more, to check your files and to do the track log import with the debugger. This is expensive and I can do other things in that time, e.g. working on things for all users or spending time with my family.
Since this seems to be an isolated problem with some of your files and most likely not an issue with the IMatch track log importer, I give this a very low priority.

You could do the analysis yourself, running the map panel in your browser (http://127.0.0.1:50519/imatch/apps/FEATURES/mapapp/index.html) and then setting a breakpoint on line 143 in "C:\ProgramData\photools.com\IMatch6\webroot\imatch\apps\FEATURES\mapapp\track\tracks.js". Then check which date and time IMatch has returned for the NEF which fails and then step thought the import where IMatch tries to match date and time information in your tack log to the timestamp of the file.

[ubacher]

I used the debugger to find the problem: For the problematic NEF file there is no timezone at the end of the xmp exif datetime.
There is a confusing difference in the output of vartoy and the output in the metadata panel.
Clearing this might then also clear the difference inside track.js

( A similar difference exists with the xmp xmp datetime.)

I am sending screen shots with added explanation plus the two files (NEF and JPG) via mail.

[Mario]

Timezones are optional. If no timezone or T or Z is provided, IMatch assumes local time.
This is usually the case, if there is no time-zone in the EXIF/legacy IPTC, no prior XMP, the user has not added a time-zone manually or automatically.

Vartoy displays date and time in the same way IMatch does by default (local time).

If the time for the NEF does not match the track, IMatch cannot map it, obviously. Have you just tired to correct the timestamp or shift the track timestamps to match your NEF? This is the usual way to deal with this.
See Adjusting the Time Zone Offset

Sending me more and more stuff will not prioritize this.
I have already 3 emails with binary attachments and stuff from you in my inbox. And 30 or so emails to deal with before I can even look at this stuff.

[ubacher]

The xmp exif date time as shown on the metadata panel shows the timezone!
Inside track.js (Line 151) the time zone is missing. BUG?

[Mario]

The xmp exif date time as shown on the metadata panel shows the timezone!
Inside track.js (Line 151) the time zone is missing. BUG?

I have no idea. Has the time-zone offset already been applied?
There are so many things which can affect this.
Dealing with this will cost a lot of time. I can tell you more in a week or so when I've worked on the support tickets created before yours.

[jch2103]

@ubacher -
See attached metadata template to show image file dates and times. It might be helpful in figuring out why some of your NEF files aren't mapping properly. I suspect some external program has changed some of your NEF dates/times; I haven't seen any similar behavior here with mine. The Metadata Analyst app might also shed some light on your situation.