Date & Time question

[ben]

Hello,

i have a question regarding date & time information in iMatch

Under "preferences -> sort profile" i can use the information "Date & Time", which is a value precalculated by iMatch.
Which is the corresponding variable name that i can use in the "file window tip"?


Thanks,
Ben

[Mario]

[File.DateTime}

[ben]

Thanks, then i am using the right variable ([File.DateTime}).

But this leads me to my next problem.
The following happens quite often:

• When i import new jpgs i usually assign them to categories and add keywords and title/description/location/country
• My file window tool tip displays [File.DateTime} and my sort profile is sorting according to "Date & Time"
• After i added the metadata and the metadata is not written back, then the Date in the tool tip is wrong. It displays the todays date (i assume it's the last modified date)
• The sort order is still correct, and the date written into the metadata is also correct (XMP DateCreated, Exif Date Created)

Unfortunately i don't have a sample pic at the moment.
Any idea how this can happen?

Ben

[Mario]

This sounds like your files don't contain EXIF timestamps or any other usable metadata date & time information.
In this case IMatch falls back to using the 'last modified' date and time as reported by Windows.

See https://www.photools.com/help/imatch/#tech_exifdate.htm for details.

If you set a proper Created/Digitized timestamp once via the Metadata Panel, IMatch will use that and also store it in the XMP metadata. This will not change when you later modify the file.

[ben]

Hey Mario,

thanks a lot.
Please have a look at the attachment.
These were the information from my metadatapanel while the tooltip showed (at this time) todays date.

For me it looks like, there were enough date information in the metadata panel.

Ben

[Mario]

What is the problem? What does {File.DateTime} return? What does the standard File Date & Time File Window Attribute return?
All these are set when the file is indexed or re-indexed.
What file format is this? A Video file? Which tags are you showing in the MD panel?
Show ExifTool Command Processor output from the "List Metadata" preset. (Attach, don't include in your post).

[ben]

Mario, i will collect the information you asked for the next time i am working on images and the problem happens again.

[Mario]

OK.
Because setting the XMP:created/digitized also sets the standard File date&time in IMatch and thus this usually "just works".

[stahl]

Hello,
I am facing a similar issue. For some reason I don't quite understand, IMatch 2017 assigned the date of the newest image in my db as {File.DateTime} to 35 other JPEGs. Apparently, this happened when I added keywords to those 35 images. Writeback is not activated and there has not been any manual writeback.

So the date tags of e.g. one of those JPEGs are:
15.06.2018 18:04:48 File.DateTime
14.06.2018 14:00:54 CreateDate
14.06.2018 14:00:54 Date Subject Created
14.06.2018 14:00:54 Original Date/Time
14.06.2018 14:00:54 Modified Date
14.06.2018 14:00:54 Windows Date

There are and have been EXIF timestamps in the JPEGs and my vintage IMatch 3.6 shows them properly. I am attaching the ExifTool Command Processor output from the "List Metadata" preset.

As a result, my timeline is messed up. And I am very sure I did not do anything with with those images at the time given by File.DateTime now, because I was having a beer in the sun at the time a good 100 km away from the hard disk with some of the images affected. What may be going on?

Stef

[Mario]

IMatch only changes the metadata date when updating the metadata in the database. It does not change EXIF date and time values in the database or on disk.
Which tags do you show in your list? Please always show the full tag name, because the name without the path is not unique.
Attach a file which produces this behavior so I can check what the problem is. I have never seen this before and I doubt that IMatch writes EXIF dates and times by accident. I could find nothing in the source code.

As a result, my timeline is messed up.

The timeline favors the XMP created date (see IMatch help for details) and this is derived from the EXIF date and time IMatch produces on ingest when it reads the EXIF timestamps in your file. If there are no EXIF timestamps, IMatch uses the best available timestamp, which is usually the "last modified on disk" timestamp. This preliminary and non-optimal timestamp is then updated when you change the XMP timestamps later, which allows you to position your files on the timeline even if they have no EXIF timestamps. See IMatch help for details.

[stahl]

Actually, I can't see that any EXIF dates or even XMP dates have been changed. The only strange date is in File.DateTime in each of the 35 JPEGS. Here the full data of the example file DSCN2381.JPG:

15.06.2018 18:04:48 File.DateTime
14.06.2018 14:00:54 File.MD.XMP::xmp\CreateDate\CreateDate\0
14.06.2018 14:00:54 File.MD.XMP::photoshop\DateCreated\DateCreated\0 (Date Subject Created)
14.06.2018 14:00:54 File.MD.XMP::photoshop\DateCreated\DateCreated\0 (Original Date/Time)
14.06.2018 14:00:54 File.MD.XMP::xmp\ModifyDate\ModifyDate\0
14.06.2018 14:00:54 File.MD.XMP::exif\DateTimeOriginal\DateTimeOriginal\0
File.MD.XMP::exif\DateTimeDigitized\DateTimeDigitized\0
14.06.2018 14:00:54 File.MD.Exif::Main\36868\CreateDate\0
14.06.2018 14:00:54 File.MD.Exif::Main\36867\DateTimeOriginal\0
14.06.2018 14:00:54File.MD.Exif::Main\306\ModifyDate\0
File.MD.Exif::Main\50971\PreviewDateTime\0

The other thing is that the time line in fact does not sort after any of these date fields, but apparently after File.DateTime (or, possibly, another field carrying the same value that I have not found yet). Thus e.g. files of these 35 with all the date fields filled with May data except File.DateTime show up in June. Also the "Capture Time" sort order does not seem to sort by anything else than File.DateTime.

I am sending you two files by email, one the example from above, the other the file that sticks out because it happens to have the exact (and this time correct) time stamp in all fields, and that seems to have been copied into the File.DateTime fields of the other 35 files.


As an aside, probably unrelated, I noticed that in the VarToy app - Browse Variables - Tag Selector, the tag names "Date Subject Created" and "Original Date/Time" stand for the identical XMP field "File.MD.XMP::photoshop\DateCreated\DateCreated\0", and I am not sure if this is intended.

I hope this helps,
Stef

[Mario]

File.DateTime is not a metadata tag, it is a variable.
This variable is based on the File Date Time IMatch manages per file. And this value is derived from a variety of metadata tags, depending on the timestamp tags available in your file. See this help topic: https://www.photools.com/help/imatch/#tech_exifdate.htm

If you change the XMP created/digitized tags, this IMatch attribute will change. And hence the variable. And hence the position of the file in the timeline.

[stahl]

That's clear to me so far. Sorry, maybe I have not been clear enough. The problem seems to be something else: Data used by File.DateTime does not seem to come from a metadata tag of the very files themselves but rather from another, not related file, which had focus when I assigned keywords to a group of 35 files that I had selected by ctrl + click and with whom I had not done anything in IMatch or another programme before.

[Mario]

How did you assign the keywords? Keyword Panel? Metadata Panel? Via the Categories Panel?  Favorite?
Which steps should I perform to reproduce this? I assign keywords very often and this has never changed EXIF or other timestamps. Only the metadata modified timestamp, which is required.

[ben]

Hi Mario,

i found a set of files, for which i can reproduce a weird behaviour of the {File.DateTime} data.
I am not sure if this is exacetly that happend the last times, but at least i can reproduce it.
I send the files via eMail, since it's 5 MB roughly.

- I use the text export to export the {File.DateTime} data
  Process dropped objects recursivly = yes
  {File.NameExt}: {File.DateTime|format:DD.MM.YYYY hh:mm:ss}


- copy the images to a folder and run the export. I get the following data
IMG-20160808-WA0001.jpeg: 08.08.2016 09:59:31
IMG-20160808-WA0003.jpeg: 08.08.2016 10:06:44
IMG-20160808-WA0005.jpeg: 08.08.2016 10:16:21
IMG-20160813-WA0000.jpeg: 13.08.2016 12:52:42
IMG-20170418-WA0004.jpg: 26.05.2018 21:57:36

- select all images

- change the data for the following metadata -> i entered "hallo" for each:
{File.MD.XMP::dc\title\Title\0}
{File.MD.Composite\Location\Location\0}
{File.MD.XMP::dc\description\Description\0}
{File.MD.Composite\City\City\0}

- press the green symbol to save the data back into the database

- run the export. I get the following data
IMG-20160808-WA0001.jpeg: 08.08.2016 09:59:31
IMG-20160808-WA0003.jpeg: 08.08.2016 09:59:31
IMG-20160808-WA0005.jpeg: 08.08.2016 09:59:31
IMG-20160813-WA0000.jpeg: 08.08.2016 09:59:31
IMG-20170418-WA0004.jpg: 08.08.2016 09:59:31

-> the first four images show the DataTime of the first file!

- writeback the metadata and run the export. I get the following data:
IMG-20160808-WA0001.jpeg: 08.08.2016 09:59:31
IMG-20160808-WA0003.jpeg: 08.08.2016 10:06:44
IMG-20160808-WA0005.jpeg: 08.08.2016 10:16:21
IMG-20160813-WA0000.jpeg: 13.08.2016 12:52:42
IMG-20170418-WA0004.jpg: 30.07.2018 00:59:23

-> the first 4 images show the original DateTime, only the last one shows the updated (today)
-> All files have written back the metadata correctly

[Mario]

Just in case, which version of IMatch are you using?

[ben]

Just in case, which version of IMatch are you using?

2018.7.4

[Mario]

Excellent!

I've figured it out (after looking at the code for quite some time). This is truly complicated stuff, several thousand lines of code are involved in writing back metadata.

It happened only during a multi-file update, if the updated files had different XMP or EXIF timestamps and only under some additional conditions. Tricky to find.
But it may have happened in such a situation that the timestamp of the focused file (which is uses as the template data source) was set as the virtual "file datetime" maintained by IMatch and exposed via the {File.DateTime} variable and other features.

The next rescan has fixed this.

Even after finding this glitch it took me quite a while to figure out consequences and side effects of the required change, because there are so many cases where setting the timestamp is required.

See also this corresponding bug report: https://www.photools.com/community/index.php?topic=8129.0

[ben]

Perfect. Thank you.

[ben]

Hi Mario,

the problem seems to be fixed for most of the files. Thanks a lot for this very quick fix!!!

I re-run the same test i described above with the same set of file i sent you.
One of the files seems to have a further problem. "IMG-20170418-WA0004.jpg"

After changing the metadata, before writing-back-metadata, the date shown is still correct.
-> your fix works

After a metadata write back and also after a force rescan, this one file shows wrong XMP (!) data.
And therefore also (of course) the {File.DateTime} is wrong.
I checked for the following tags and they all show the date and time of when i actually changed the metadata:
   {File.MD.XMP::photoshop\DateCreated\DateCreated\0}
   {File.MD.XMP::xmp\CreateDate\CreateDate\0}

Can you confirm this behaviour on your machine?
iMatch 2018.7.6

[Mario]

Please open a separate bug report. I cannot track bugs reported in General Discussion. You can just link to your last post.

[ben]

Please open a separate bug report. I cannot track bugs reported in General Discussion. You can just link to your last post.

I opened a bug report here:
https://www.photools.com/community/index.php?topic=8175.msg57446#msg57446