Need noob help with searching Metadata for dates

[Panther]

I decided it was finally time to try learning something about how to search on metadata.  After plowing through the mindboggling complexity of the help file with its extremely voluminous info about metadata (all of which is great for those who need that much detail but most of which is way over my head and more complicated than I need for the few little simple things I really want to be able to do with metadata), and playing around with the metadata panel and filter panel and reading through several pages of old forum posts for a couple of hours this afternoon, I'm still at a loss to figure out how to do a couple of what are probably very simple things.

First, I did manage to figure out which fields the default metadata panel I had been using corresponded to the tags/fields that the tag selector was showing me, and to create a simplified custom metadata panel that just shows the few tags/fields I know that I want to use (so far).

Second, I also figured out how to use the filter panel to do a simple search on those few selected tags/fields and locate files that contained the specific, simple search word anywhere in those few selected tags.

So far, so good.

BUT, then came the two problems I've hit a wall on.

1.  I want to be able to save several versions of search/filters, e.g., one that searches all of my selected tags, one that searches only on author, one that searches only on date created, etc., so I can pick them off the menu/dropdown or whatever without having to manually go through adding/removing selected tags every time - I found a save function that seemed like it was going save the filter down as a new filter under a new name, and I found where it was adding those new entries onto the dropdown list, BUT I could not figure out how to click or unclick things so that it would actually apply those new filters to find the right files that way.

2. Even more distressing, I can't even figure out how to search for a specific date in the date created tag/field.  As you can see from the screenshot below, if I search/filter on simply "1917", it will pull up all the files that have "1917" in the date created tag/field, including the one highlighted in the screenshot below as having been created on "1/4/1917" - so far, so good:

ACTIVE LINK TO EXTERNAL WEB SITE REMOVED BY ADMIN.

BUT, when I try searching/filtering on "1/4/1917", it fails to pull up any files (and I tried a few other variations on the date theme, and couldn't find any that worked):

ACTIVE LINK TO EXTERNAL WEB SITE REMOVED BY ADMIN.

I could really use some sort of simple tutorial on searching metadata in iMatch, but for right now I'd love to just get a tip from someone as to how to search for dates.  One other problem I'm having is that I can't seem to find a good tag/field to use for dates when I do not have the full info (e.g., when I only have the year, or perhaps year and month) - the method of entering the date into the date created tag/fields I've found all seem to require you to know (or at least enter) the full/exact date (and even time), but I'm going to need to be able to enter and subsequently search on partial dates in some (hopefully) easy fashion.

Any help from anybody familiar with this searching stuff would be greatly appreciated.

[EDIT] I've attached the two screenshots I tried to link to above (sorry about that).  Probably got the answers I need in subsequent posts below, but thought it might be helpful to show what I was talking about.

[Mario]

The easiest way to lookup files by date is the Timeline View in IMatch. Work with the system, not against it.
Select the time range you want to look at in the Timeline View first.
Then optionally apply additional filters in the Filter Panel or use the file window search bar to search metadata.

Don't use the Metadata Search when you have problems with it. You picked a very complicated filter for your experiments.

The Metadata Search is a flexible tool to search all the metadata contained in your files.
When you use a mode like "contains" you have to make sure that the text you enter appears exactly in the metadata.

BUT, when I try searching/filtering on "1/4/1917", it fails to pull up any f

Sure. Metadata may not be formatted the way you think it is. While IMatch uses your local date and time format in the Metadata Panel, the actual metadata in the file may use a totally different formatting. In many cases metadata date and time information is stored in an ISO format, e.g. "YYYY-MM-DD HH:MM:SS".

For your example, the metadata in the file is most likely stored as 1917-04-01 and you search for contains 1/4/1917". Naturally, you won't find anything.

I suggest you use a Value Filter instead. They are much easier to use.

After selecting the Date and Time metadata field you want to use, the filter shows you all values for your current scope (for all files currently in the file window). You then only need to pick which dates you are interested in. This works the same with other metadata like locations, titles, descriptions etc.



No need to figure out how the metadata is formatted. Just click the elements you are interested in.

And, if you want to filter for dates, the Date Filter is usually the better way to do it:




PS: Please do not include active links to external sites in your posts. You embedded links to the photo bucket site and this means that the IP address of every photools.community member who opens your post is transferred to the external web site. The site may even set cookies or plant tracking info, I don't know. I have removed the live links from your post.

Please use the attachment option available for every community post to attach images and other stuff to your posts.
Just click on the Attachment and other options link below the post editor to attach files.

[BanjoTom]

Panther, I agree with everything Mario said and recommended in his reply to your question about searching for dates.  But you should probably also read the thread called "Developing a strategy for unknown or imprecise dates" -- which you can find by typing that subject into the Search bar at the upper right of the Photools.com forum page. 

That will lead you to an excellent discussion of the subject.  I have used the suggestion that someone made in that thread about adapting a little-used metadata tag for entering such dates.  You can use either {File.MD.XMP::dc\coverage\Coverage\0} or {File.MD.DarwinCore::Main\EventVerbatimEventDate\EventVerbatimEventDate\0} for such purposes, and put into those metadata fields either general terms indicating imprecise dates, for instance: "c. 1975" or "c. 1975 January."  And/or, you can implement the detailed suggestions by the Library of Congress (also referenced in that thread), using "X" or "?" for documenting unknown or imprecise dates. 

I've added both those metadata tag fields to the Default listing in my Metadata panel.  In the metadata for a file in my database with that problem, they look like the first attachment to this message.  I still have a lot to learn about how best to handle this, but there ARE ways to do so in IMatch; and once you've set up that sort of metadata tag to handle your documentation of imprecise/unknown dates, it's easy to make sure that any formatted output you create (e.g., in your File Window Tips, or in Design&Print templates, or in Presets you create for the Image Batch Processor) outputs a precise date you've assigned to a file UNLESS one of those additional metadata tags is populated, in which case the "circa" date can be shown instead.  I've attached a second image showing that sort of output from the Image Batch Processor as well. 

Hope these suggestions help!  And I know from experience that you will find a LOT of great help on this forum from Mario, and also from a wonderful international group of expert users who have previously worked through most problems you'll likely encounter . . .

[Mario]

Very nice, thanks.
Uncertain dates are always a bit of a nuisance because they are not really supported by anything that displays dates, performs calculations with dates and so on.

I also recommend usually to use a metadata tag. And to stick to a common formatting.
This makes it then very easy to use uncertain dates in IMatch, for searching, sorting, you can automatically group your files into data-driven categories using that tag and so on.

And it's also fairly easy to 'produce' well-defined dates from the uncertain dates e.g., by using an IMatch Metadata Template - in case you need to deliver your files or you need to adapt them to a different way of recording uncertain dates.

[Panther]

Thanks for the replies - looks like I have some more digging to do to find the right approach here, but it looks like there are probably a few good options to choose from.

And sorry about the links to the screenshots - that's the way everybody posts screenshots on the only other couple of forums I frequent and I didn't realize that would cause problems - I'll try to remember not to do that again.

[Erik]

For unknown dates and times, I just generically set photos to an estimated date with a time of 00:00:00.

I suspect that in reality, I would rarely have photos at exactly the time 00:00:00 on any day, so that is my way of knowing that I don't know the time or that the rest of the date may be a guess.

As for the date, if I know the year but nothing else, I set the date to YYYY-01-01 (I used to successfully use 00 as a day of the month, but I'm not sure Exiftool allows that... I used to use a different software, which wasn't so picky about the dates being real).  If I know the month, I just put in the right month but leave the date at 01. 

I know by the time of day when the information is likely an estimate (i.e. the 00:00:00).  My file naming scheme also relies on date and time, so the 0000 (HHMM) ends up in the file name and gives me something to build a data driven category on for estimated dates and times. 

In reality, I find that I rarely care about whether the time was accurate (usually from the camera) or guessed (scanned film or slides).

[Panther]

I checked out the timeline view, but if I understand it correctly (after reading through the help file) it only works on the date the file itself was created, which does me no good for what I need (all my files were created very recently when I scanned the photos/documents, but I need to deal with the date the original image/document was created, which is what I've been putting into the metadata).

The Value filter idea still sounds promising, and I'll check it out later tonight or tomorrow.  I guess I'll also need to take a look at the data-driven category idea, though I haven't done anything with those yet and, while obviously pretty powerful, they always seemed pretty complicated as well. 

I had figured I might need to use/adapt some other metadata tag to enter the dates so I could deal with partial dates (and I will be taking a look at those suggestions/threads as well - thanks!), but I figured I had to learn the basics of how to search on the metadata to begin with or having it in that adapted tag would't do me much good.

So much to learn - so little time

[Panther]

Ok - I played around with the value filters, and they were pretty interesting, but the idea of having to scroll down a long list of possible values to check the one(s) for the dates I wanted seemed a little kludgey.  But it did confirm the format that the dates were being stored in for any given tag, which proved useful for trying to figure out how to search for the dates in that tag and gave me some good ideas about how to enter indefinite dates, so I started experimenting some more with adapting a different metadata tag in which to enter my full/partial dates without using one of the official date tags that expects its own particular format.

Everything seemed to be going fine, but then I ran into some really odd behavior that I don't understand.  The attached screenshots tell the tale, but I'll try to explain what is happening in hopes somebody can explain why (and how to stop it).

First - I had previously entered dates for some of my files using the tag called "Date Subject Created".  As shown in the first screenshot, when I do a value filter on that tag, it shows the values I've put in that tag, and when I check one of the boxes and apply the filter it shows the one file with that particular value - so far, so good.


Second - I added a custom date into a different tag (I borrowed/adapted the tag called "User Comment" for this purpose) for that particular file, and then used the command menu to tell iMatch to write back the metadata for this file.  This is where things started to get weird.  As shown in the second screenshot, the value filter still shows that same date/content to be in the original tag (Date Subject Created), but when I check that value and apply that filter the program no longer displays any file.

Third - when I turn the value filter off, and turn on the metadata filter and search for the date I just entered into my custom date tag ("User Comment"), the program finds and displays the right file for which I added that custom date (that part's good!)

BUT (and this is where it gets really weird to me) I noticed that the entry in the original tag (Date Subject Created) for this file has now been changed, and the date I had originally entered into that tag has been lost and replaced with the same info as is in the Date Digitized tag (which I relabeled for my layout but which is the "Date Created" tag). 

Why did that happen?  That "Date Subject Created" tag was still showing the correct date (the one I had previously entered) when I used the command to write back the metadata, with the different (but correct) date digitized showing in the "Date Created" tag, and I didn't tell it to change the "Date Subject Created" tag, so why did it replace the info in that tag just because I wrote back the metadata?

[Panther]

Hmm - well, I think I stumbled onto the reason that this is happening - something somewhere seems to be equating two seemingly different tags as being the same thing.  I played around with the value filters some more and discovered that the "User Comment" tag I was putting my test dates into was apparently also the same tag as the "Description" tag I'd been using for something else (even though in the tag selector they are seemingly different tags).  I guess the same thing must be happening between the "Date Created" tag and the "Date Subject Created" tag that I thought were separate as well.

Guess I'll have to read up more and try to figure out which of these tags are actually separate/distinct from each other and which ones are treated as being the same. 

Is there some easy place in iMatch (or the help file) that I haven't found yet that explains which groups of tags are equivalent to each other and which ones aren't?

[Mario]

As explained in the IMatch help in full detail, IMatch applies the rules of the Metadata Working Group when you work with metadata. Part of that is the mapping of certain metadata fields between different metadata standards. IPTC to EXIF to XMP to GPS and all around.

You are fiddling with non standard fields. User Comment is an EXIF tag that is meant to be set by the camera. It was also used by software 10 years ago, when the other software did not speak any of the proper metadata standards. This field is synchronized with the legacy IPTC caption and the XMP description, which is what you saw in IMatch.

Don't make your own life so hard. Don't change arbitrary metadata just because you think it's the right thing. Stick to the standard tags IMatch provides in the Default metadata panel for safe operation. There are so many dependencies between EXIF, GPS, XMP and IPTC that it can make your head spin. Which is why IMatch by defauld hides all the complexity and presents a safe and sanitized list of metadata tags to you.

Other than other software, IMatch gives you access to all metadata in your files. This is considered to be an Export Option. You can safely display all data, but when you start to change non-standard data (especially non-XMP data) you should take the time and read the corresponding standard document or description to see what changing that tag means, and if you should change it at all.

The EXIF User Comment is just one of these potentially dangerous tags.

If working with date and time is so important for you, I suggest you adapt one of the workflows suggested above and then manage your files by date and time with the various features provided by IMatch for that purpose. Managing files by date and time using ground level metadata tags is way to complicated and slows down your workflow.

And sorry about the links to the screenshots - that's the way everybody posts screenshots on the only other couple of forums I frequent and I didn't realize that would cause problems - I'll try to remember not to do that again.

Most users have just been trained to not understand what links like this really mean. When you put a live link like that into your post, and a community member here opens your post, the browser will connect to the other side, to download the image. OK so far. But...

... this also means that the browser transmits a lot of information to the other site, including the unique IP address of the user, and most likely a bunch of 3rd party tracking and advertisement cookies, Google and Facebook cookies and whatnot - depending on which marketing networks photo bucket is part of and if it cooperates with FB and Google.

All this allows these 3rd parties to track photools.community users without their knowledge or explicit consent. And this is why I don't like it and don't want it here.

[Panther]

OK - I'll keep looking into those other workflow suggestions. 

I tried using just tags from the "standard" set, but even some of them seem to be overlapping/used as equivalents.  Maybe something in those other suggestions will help identify tags that are sufficiently independent of other ones to be safe to use.  The date filter looks promising as a way to deal with searching based on dates, but if I understand it correctly it only seems to be working with tags that I can't safely rely on to enter my own dates into (without them getting overwritten by file-related system-generated dates). 

I understand the complexity of all these competing/different sets of metadata tags and appreciate the efforts to simplify their presentation in iMatch (I like simple ).   I'm a little surprised that there doesn't seem to be something pretty standard and obvious that could be used by humans to specify a significant date, without interference from the dates set by cameras/devices or file/operating systems, but I'll keep looking - I'm sure the answer is in there somewhere.

[hluxem]

I use the following tags for my scanned pictures and slides:

XMP::exif\DateTimeOriginal\DateTimeOriginal\0
XMP::photoshop\DateCreated\DateCreated\0
XMP::xmp\CreateDate\CreateDate\0

I did a lot of tests, I think at the beginning the use of composite tags was recommended, but that changed and the tag is now locked. Using these tags works for me, it even works for videos and I don't need any value filter because all files are nicely displayed in the timeline. The tags have to be formatted correctly and you can't just write part of the date. But once you have the date in the file, it can be read by other software and you can sort the pictures in Windows Explorer for time as well. My goal is to be able to display the files which could be videos, scans of pictures or slides sorted by date taken. With limited data available, you have to make estimates. For my scanned files from 60 years ago I'm 99% sure that I got the right sequence, the date value maybe off. It doesn't matter much to me if a picture in 1960 was really taken on August 1, I never find out if it's wrong or right :>).

I use a similar strategy as Erik for my estimated dates. I was lucky enough to have the year marked on all pictures, from there I looked for holidays, special events like a wedding or season of the year and filed in the date. I use some categories to identify if the date is estimated, but don't really use them. I think it's easy to set the right tags with the metadata templates, I do use a script to set the values because I increment the time by 10 s in order to maintain the sort order. That is important for me because I do have a mix of slides and negatives and they are named differently.   

[Mario]

I'm a little surprised that there doesn't seem to be something pretty standard and obvious that could be used by humans to specify a significant date, without interference from the dates set by cameras/devices or file/operating systems, but I'll keep looking - I'm sure the answer is in there somewhere.

The XMP created date is the most significant date. It is set by the camera when the image is created, or by the imaging software that has created the file. The digitized date is usually identical, except you use a scanner to scan photos and thus the creation of the digital image is different from the creation date of the actual photo.

These two XMP dates can be changed by users. IMatch automatically synchronizes them back into EXIF and (legacy) IPTC as needed.

This is why these two dates are in the Default metadata panel layout. IMatch also uses these tags for digital images to define "the" date and time it uses for the "File Date and Time" variable and the corresponding IMatch attribute, the time-line and many other functions. If you change these dates, you can move you file around on the time-line in IMatch.

See "EXIF date and time" in the IMatch help for a full explanation about these dates, and similar timestamps available in other file formats and how IMatch uses them.

There is also a a modified date which is set by software when it modifies your files. And a metadata modified date, which is updated by IMatch when it modifies the metadata in your files.

[jch2103]

As you've already discovered, metadata tag names are confusing and don't always describe the metadata tag you actually want.

You may want to take a look at https://www.photools.com/community/index.php?topic=1129.0 which discusses tags to use for scanned images. hluxem also discusses these tags in a recent post in this thread. As Mario notes, these tags are included in the Standard tags group.

If you use these tags, especially XMP Photoshop Date Subject Created (Original Date/Time) for when the imaged object was originally created, you'll find that the Timeline correctly sorts your images by date.

[Panther]

I'm still exploring whether there is some sort of isolated/independent metadata tag that will let me do what I want, BUT in the meantime I'm still running into the bizarre tag-overwriting behavior that I posted about last night. 

I tried another test tonight, making sure to confirm that I had actually used the right two specific tags from the "Standard Group" mentioned in some of the other threads/posts people here have mentioned ("Date Subject Created" and "Created Date"), and somehow the process of changing the entry in a completely separate and seemingly unrelated tag ("Description") and then using the Command menu to write the metadata back to the file is still causing the pre-existing entry in the "Date Subject Created" tag to be changed and over-written with the pre-existing entry in the "Created Date" tag.

Why is iMatch changing that entry when I didn't ask or want it to be changed, and why is it insisting that the entries in these two tags be the same?  At some point in the past with previous versions of iMatch 5.5,  iMatch has clearly been capable of treating these two tags as separate/independent, since the entries in those two tags were still reflecting the correct, different dates/times they had back then when it pulled up and displayed the file using my custom date (in the "Date Subject Created" tag) in the value filter using the current version tonight.  But as soon as I write back some other, unrelated metadata to the file, iMatch has wiped out my previously manually entered date/time in the "Date Subject Created" tag and replaced it with the camera-generated date/time that was in the "Created Date" tag.

With this sort of uncertainty as to what will happen to the contents of these tags, I guess I won't be using either one of them for my date-related efforts here.  But I'm still curious - is this behavior really normal/expected, and is there any way to stop this behavior from occurring?

[EDIT] - been doing some more tests - does anybody know any reason why the standard tag for "Copyright" wouldn't be a good tag to adapt and use to manually enter user-created dates?  It seems to have been working pretty well so far, and it seems like a very logical place to put the date the underlying image/document was created (and I have no need to specify or track any copyright-related info in connection with the files I'm cataloging), but I'm just wondering if maybe there's some hidden problem or reason using that tag isn't a good idea?

[jch2103]

I'm still exploring whether there is some sort of isolated/independent metadata tag that will let me do what I want, BUT in the meantime I'm still running into the bizarre tag-overwriting behavior that I posted about last night. 

I tried another test tonight, making sure to confirm that I had actually used the right two specific tags from the "Standard Group" mentioned in some of the other threads/posts people here have mentioned ("Date Subject Created" and "Created Date"), and somehow the process of changing the entry in a completely separate and seemingly unrelated tag ("Description") and then using the Command menu to write the metadata back to the file is still causing the pre-existing entry in the "Date Subject Created" tag to be changed and over-written with the pre-existing entry in the "Created Date" tag.

Sorry, I'm not completely clear on which metadata tags you're using. As I noted above, several of the date-related tags have names that are not clear or are confusing or misleading (NOT Mario's fault). Perhaps you can list the 'long form' of the tags you're using, e.g.:

(From https://www.photools.com/community/index.php?topic=1129.0)
Click the 'Standard' tab. Scroll down to find 'Created Date' and double-click to add it to the 'Selected Tags' box below (you'll see 'XMP xmp\Created Date'). Then scroll down further to find 'Date Subject Created' and double-click again (you'll see 'XMP Photoshop\Date Subject Created'). Click OK to select the two tags.
The tags will now appear in the Tag Selector dialog, with a caption automatically supplied. However, you may find the captions a bit confusing because they're so similar. I'd recommend this for captions:

'XMP Photoshop\Date Subject Created' --> Original Date/Time
'XMP xmp\Created Date' --> Digitized Date/Time

If you're using these tags, there shouldn't be an issue with having tag values overwritten. Or, at least, no one else has reported an issue.

[sinus]

[EDIT] - been doing some more tests - does anybody know any reason why the standard tag for "Copyright" wouldn't be a good tag to adapt and use to manually enter user-created dates?  It seems to have been working pretty well so far, and it seems like a very logical place to put the date the underlying image/document was created (and I have no need to specify or track any copyright-related info in connection with the files I'm cataloging), but I'm just wondering if maybe there's some hidden problem or reason using that tag isn't a good idea?

I am not a metadata-guru (phew, what a mess there), but I think, there is nothing to say against using this field. I am using it since years with some copyright-text, if you enter "copyright by ...." or a date, I see no difference.

[Mario]

IMatch does not change arbitrarily metadata tags. It synchronizes certain tags while you work with them (e.g. hierarchical keywords into flat keywords) and it performs MWG-compliant mapping (what you probably call overwrite) of XMP data into EXIF/IPTC/GPS on write-back - and from EXIF/IPTC/GPS into XMP on reading metadata.

You seem to have strange and unique issues with the metadata. From experience we know that this is either caused by how the user works with metadata or by inconsistent or corrupted metadata in files.

To gather more info about your problem:

1. Please give us the precise tag names you change. You can right-click the tag in the Metadata Panel and then use "Copy as Variable". Paste the name into your posts so we know which tags you are using.

2. Enable verbose output for ExifTool under Edit > Preferences > Application: "Settings" group > ExifTool Verbose Logging.

3. Open the ExifTool output panel via <F9>,<O> or View > Panels > ...

When you now write back metadata to a file, the panel will record which data IMatch writes, and where. Copy, paste into a Notepad, save as text file and attach to your reply. This way we can see which tags you have changed, if ExifTool is writing them correctly etc.

[Panther]

Mario - thanks for the reply.  I did what you said (I think) and have attached the text file into which I pasted the EXIF output from a couple of tests (as well as the full/formal names of the two tags involved).  There's some kind of error message in there, but I don't know what it means.

Unfortunately (for troubleshooting purposes at least) I have not been able to replicate the over-writing behavior I was seeing.  All of the files that I had available for testing that previously had different date/time entries in the "Date Subject Created" tag had already been overwritten in the previous tests, and so far with the files that I have gone in today and manually added a different date/time entry into that tag before running the test, that tag has not been over-written by subsequent saving of metadata into the other tags.

I may still have a backup set of copies of these test files somewhere that I can try again on, but I'll have to check that out later tonight when I get back from work.

I've also been experimenting with putting my manually-entered dates into the "Created Date" tag instead of the "Date Subject Created" tag, and so far that tag has never been over-written in my tests either.

Maybe there was some sort of corruption in the metadata in those files after all.

[Mario]

Output looks good. Only the standard warning about missing 1/100 time data for EXIF (normal for most images).

IMatch only updates a small set of XMP data:

-XMP-photoshop:DateCreated=1916:11:23 09:50:09.00-04:00
-XMP-exif:DateTimeOriginal=1916:11:23 09:50:09.00-04:00
-XMP:CreatorTool=photools.com IMatch 5.6.0.22 (Windows)


and then runs the ExifTool arts files to perform the mapping between XMP and EXIF.

[Panther]

Well, I've banged this around another 20-30 times (with some of the same and some different files) and have not been able to replicate the over-writing issue between these two date/time tags.  Whether I start with modifying one tag, or the other, first I haven't seen any over-writing of either tag by the other.  That's good, of course, though it does make me wonder what sort of corruption or problem with the workflow that there might have been that was causing the problem the other night.  The only possible difference I can imagine is that when I was seeing the over-writing issue the other night I was using the value filters to locate the files - so maybe that had something to do with it (seems unlikely, but I just realized that I had stopped doing that in these most recent tests, so I'll have to go back and try to replicate that aspect to see if it might have had anything to do with it).

[EDIT] Interesting - I could not replicate the exact same over-writing problem yet, but there's definitely something odd going on with that same "Date Subject Created" tag that I was having the problem with before, and it seems attributable to or connected with using the Value filter while doing the metadata editing/write back process.

I've attached a sequence of screenshots illustrating what happened (the second time I tried it, after noticing it the first time without the verbose output turned on), as well as a text file into which I have pasted the EXIF output generated during the metadata writing process for that second test.  This time, it did not replace my custom date/time entry with the one from that other tag like it did the other night, but it did truncate/remove part of the entry in the process of writing new metadata to a different. unrelated tag (the "Author" tag, in my tests).  As shown on the screenshots, that custom entry started out being "11/9/1916 12:00:00 PM-04:00", but after the metadata writeback process it has been changed to read just "11/9/1916 12:00:00 PM".

Why is this tag being touched at all during the write-back of a different tag, and why is the "-04:00" being removed from the end of the entry in the "Date Subject Created" tag?

I suppose I can avoid having this issue by just not using the value filter (as all my tests where I didn't use the value filter seemed to leave these other date tags untouched), but should it really be doing this at all?

(I had to zip the screenshots along with the text file as they totaled a little over the limit, but the images are file-name-numbered in the order in which the test progressed.)

[Mario]

If you have problems with time zones, please see the notes about the standardized ISO date and time format and time zones in the IMatch help.

You have apparently updated the "Author" tag in the Metadata Panel.
This is another one of the special tags. The Author tag, sometimes called artist  or creator and in the IPTC standard it's called By-line is mapped between -XMP-dc:Creator, -XMP-tiff:Artistm, EXIF Artist and IPTC By-line by rules defined by the metadata working group. This is why IMatch here writes the data to several tags.

The ExifTool output shows IMatch correctly updating tags, also the mapped tags.

No date or time information is changed in thsi call, except the Metadata and Modify date, which is correct.


-XMP-dc:Creator=
-XMP-tiff:Artist=
-XMP-xmpDM:Artist=
-XMP-dc:Creator=test
-XMP-tiff:Artist=test
-XMP-xmpDM:Artist=test
-XMP:CreatorTool=photools.com IMatch 5.6.0.22 (Windows)
-xmp:InstanceID=xmp.iid:b7767712-9ce5-4b64-b20f-e795079fa766
-XMP:MetadataDate=now
-XMP:ModifyDate=now


I'm not sure what you want to tell me with the screen shots.
Did you perform metadata updates while a filter was active? Maybe just disabling and re-enabling the filter would be sufficient, to make it reload the now new data from the database?

You are using a PM time format in your Windows. To see the real date information, please click into the field. IMatch then shows the date and time information, with time zone offset as delivered by ExifTool.

Note that when you change date and time  in IMatch, IMatch stores them in your local time zone, and records that in the file. If your local time zone is different from the time zone initially stored in the file, the time information will change necessarily - because IMatch only shows time zone offsets if there any. After changing a time value, it will be in your local time zone, and thus IMatch will not display a time zone offset anymore. That's correct and expected.

This is explained in the help in detail. Date and time information is always confusing for users and messy, especially when you change it and you work with metadata standards like EXIF which have no idea about time zones and XMP, which has. Oh, and IPTC also has time zones. Best to not think to much about it and let IMatch do its job.

[Panther]

Mario - the point of the screenshots was just to show you the progression of steps I followed and how the "-04:00" (which I presume is the time zone offset indicator) is getting removed from the entry in the "Date Subject Created" tag when all I'm trying to do is add/change the entry in the "Author" tag.

I assume there's no problem with me using the "Author" tag to store the name of the author/creator of the image - even though you state it is somehow a "special" tag, it's one of the ones in the "standard" list of tags in iMatch's Tag Selector and none of the other tags iMatch is writing the author info to seems to have anything to do with any of the date/time fields, as one would expect.

And I don't really have "problems with time zones" generally.  When I manually selected the date to enter into the "Date Subject Created" tag using the calendar that iMatch provides for that purpose, it entered that date as "11/9/1916 12:00:00 PM-04:00", with the "-04:00" at the end (of course, it actually entered it as "1916:11:09 12:00:00 PM-04:00", and just displays it the other way because of Windows settings as you previously explained, and I can see/confirm that by clicking in that tag as you also explained).  That entry stays the same (with the "-04:00" present) when I write that date-related metadata back to the file, and every time I call that file up and look at that tag during "normal" operations the "-04:00" is still there.

But then, for some still puzzling, so far inexplicable reason, when I have the value filter on finding that file by ticking the "1916:11:09 12:00:00 PM-04:00" value, and add/change the entry in some other tag (such as author, or description), without touching or changing the date/time entry myself at all, when I write that other metadata back to the file iMatch changes the entry in the "Date Subject Created" tag and gets rid of the "-04:00" at the end, all on its own.  iMatch put the "-04:00" there when that date/time was first entered, kept it there during all sorts of other activities dealing with that file, and then just decided to throw it away while writing back some completely unrelated piece of metadata to the file. 

You stated that the EXIF output indicated that "No date or time information is changed in thsi call, except the Metadata and Modify date, which is correct", yet the entry in the "Date Subject Created" tag was definitely also changed during this process (the "-04:00" was removed), as demonstrated by my screenshots, so why isn't that reported in that output?

Is it just me that finds that behavior a little odd and sort of scary, that the values in that tag would be changing unintentionally (from the user's perspective) like this?

(and yes, this only seems to be happening when the value filter is being used, and thus the problem can hopefully/presumably be avoided by just not using the value filter during metadata write-back activity, but doesn't that indicate that perhaps there's some sort of weird bug in the value filter mechanism that's causing this unintentional alteration of unrelated tag entries?)

[Mario]

The author tag is meant to store the author of the photo. As long as you use the official XMP cretor tag (IMatch Metadata Panel: Author) you're good.

Maybe your file had no valid dates before and thus IMatch / ExifTool filled them from the last modified time on write-back? This would be normal.

[Panther]

Maybe your file had no valid dates before and thus IMatch / ExifTool filled them from the last modified time on write-back? This would be normal.

Maybe this key point got lost in the admittedly long text wall of my previous post.

The files certainly did appear to have a valid date in the "Date Subject Created" tag - I entered it myself using iMatch's calendar entry method, and when I picked the date and specified noon iMatch populated that tag with "1916:11:09 12:00:00 PM-04:00".  I then wrote back the metadata to that file, and everything seemed fine - that same entry ("1916:11:09 12:00:00 PM-04:00", always with the "-04:00" at the end) was preserved and always showed up when I went through a number of normal activities (playing around with the timeline view, searching on various metadata tags with the metadata filter, etc.).  And when I turn on the value filter for the "Date Subject Created" tag, one of the values it has on the list is "1916:11:09 12:00:00 PM-04:00", and when I tick that value iMatch displays this particular file, just as I would expect.  So, it seems clear that this value ("1916:11:09 12:00:00 PM-04:00") is validly in the file and iMatch knows it.

BUT, after finding the file with that value filter, and with the value filter still on, I add (or change) some entry in the "Author" tag (or the "Description" tag - it happened with both such tags on separate tests), and then - without me touching the date/time entry in the "Date Subject Created" tag - I tell iMatch to write the metadata back to the file.  That's when iMatch changes the entry in the "Date Subject Created" tag by removing the "-04:00" from the end, even though all I had changed and all I expected iMatch to do was update the contents of the Author (or Description) tag.

Surely that can't be working as intended?

[Mario]

Did you keep the ExifTool output panel contents from that session.
IMatch knows which tags have changed and only writes the tags you have changed. If you did not change the data, it will not be marked as dirty and thus not written.
We would need the output panel data and the original file before you made the change to see if this is somehow caused by the metadata in your files. I don't recall a similar case and this is now a very long thread already. If you consider this a bug, please open a bug report, include a link to this topic, copy/paste your last post into the bug report, attach the output panel text and a sample image file which allows me to reproduce this effect. I will then look into this for a future update.

[Panther]

OK - will do.  Thanks.