Modifying "Date Created" doesnt update the File Date

[muggost]

Maybe I missed something but in earlier versions of Imatch, modifying Date Created and writing back metadata also updated the corresponding file's "Date Taken" value. Now it doesnt...? Is this an intentional change or a bug or do I do something wrong? See attachment.

[Mario]

I'm not sure where Explorer gets this information from. Is this not the "last modifed" timestamp? Explorer can show you different timestamps, make sure you pick the right one.

Did you check the file in the ExifTool Command Processor? If the file has the correct date and time in the XMP/EXIF metadata (Windows Explorer may pick any), IMatch did a proper job.

[muggost]

There is definitely something weird going on thats changed since last time I used Imatch. I think that was one of the november 2017 versions.

EXIF Tools gives this output:

Code Select Expand


[File:System]   FileModifyDate                  : 2018:01:03 12:26:44+01:00
[File:System]   FileAccessDate                  : 2018:01:03 11:22:08+01:00
[File:System]   FileCreateDate                  : 2018:01:03 11:22:08+01:00
[XMP:XMP-exif]  DateTimeOriginal                : 1905:02:01 12:00:00
[XMP:XMP-photoshop] DateCreated                 : 1905:02:01 12:00:00
[XMP:XMP-xmp]   CreateDate                      : 2018:01:03 12:00:00.00+01:00
[XMP:XMP-xmp]   MetadataDate                    : 2018:01:03 12:26:44+01:00
[XMP:XMP-xmp]   ModifyDate                      : 2018:01:03 12:26:44+01:00
[ICC_Profile:ICC-header] ProfileDateTime        : 2006:02:02 02:20:00


If I modify the File's "Date Taken" property, Imatch updates the corresponding value "Date Created" correctly. But the other way around doesnt work. I know this used to work previously because I've being doing this process for my scanned images for years...

As long as I can find another way to make Imatch update the file date, that would be sufficient.

[muggost]

No actually, Imatch doesn't update the dates correctly. At least not the way it used to:

When I modify the file's "Date Taken" property (in explorer), Imatch updates the "Date Digitized" in Imatch.
When I modify the file's "Date Created" (in Imatch), nothing happens with the file in explorer.

[muggost]

And weirder still, try this in succession:

Original file has Date Taken / Date Created / Date Digitized 01.06.1985 in both explorer and imatch.

Modify "Date Digitized" to 1986 in Imatch: nothing seems to happen in windows explorer.
Modify "Date Taken" to 1987 in Explorer: Date Digitized updates to 1987 in Imatch.
Now modify "Date Digitized" to 1985 in Imatch: "Date Taken" shows 1987 in explorer, "Date Digitized" shows 1985 in Imatch and "Date Created" shows 1987 in Imatch (without me changing the last field!).

This cannot be expected behavior! The error is reproducable by follwing the steps above.

[Mario]

The tag named "Created Date" in the Metadata panel updates the XMP::xmp\CreateDate\CreateDate tag.
The tag named "Date Subject Created" in the Metadata panel updates the XMP::photoshop\DateCreated\DateCreated tag

I've made a test, in the Metadata Panel setting

+ Created Date to 2018:01:01 11:11:11
+ Date Subject Created to 2018:02:02 12:12:12

after write-back, the file shows this in the XMP:


[XMP-exif]      Date/Time Original              : 2018:02:02 12:12:12
[XMP-photoshop] Date Created                    : 2018:02:02 12:12:12
[XMP-xmp]       Create Date                     : 2018:01:01 11:11:11


which is correct. The Metadata Date and Modify Date are set to the current date and time:

[XMP-xmp]       Metadata Date                   : 2018:01:03 13:48:45+01:00
[XMP-xmp]       Modify Date                     : 2018:01:03 13:48:45+01:00


also correct.

Windows Explorer shows me in the "Date" column 2018:01:01 11:11:11 which is also correct. It shows the same value also for "Date Taken".
"Date created" shows a date in December (which is correct, I created the file in the file system at that time).
"Date modifed" shows the current date and time.

I repeat the same for an image which has EXIF data (not just XMP). Here I get:


[ExifIFD]       Date/Time Original              : 2018:02:02 12:12:12
[ExifIFD]       Create Date                     : 2018:01:01 11:11:11

[XMP-exif]      Date/Time Original              : 2018:02:02 12:12:12
[XMP-photoshop] Date Created                    : 2018:02:02 12:12:12
[XMP-xmp]       Create Date                     : 2018:01:01 11:11:11


which is identical, and correct.
But Windows Explorer shows for this file (TEST.jpg):



It seems that Windows Explorer picks different tags, depending on whether or not the file has EXIF or only XMP data...?
I would never trust or use Windows Explorer for that. I did not even find a reliable documentation about which metadata it handles, under which conditions and file formats.

[muggost]

Maybe its Windows 10 thats changed. There was a huge update recently, called the "Fall Creators Update" or something. Maybe they did change something that causes unexpected results in Imatch.

I need to find a workaround then. I found that I can also change the "PDF Created Date" in Imatch. It also updates the "Date Taken" file property.

[Mario]

I can only say that IMatch updates the correct metadata values with the correct data. No change in that for a long time.
What Microsoft does in Windows Explorer was always a bit of a riddle for me. Especially since they seem to prefer EXIF over XMP. Sometimes.

I would not add PDF metadata tags to image files.  This may be possible but may break your files in another application. Now or later.

I would give Microsoft a call and ask them to perform the same analysis I did for you for free just now.
If you have a support contract, such a support incident will cost you between 200$ and 499US$, depending on your contract level and SLA.

[muggost]

I would give Microsoft a call and ask them to perform the same analysis I did for you for free just now.
If you have a support contract, such a support incident will cost you between 200$ and 499US$, depending on your contract level and SLA.

Ok... You really know how to make your customers feel insignificant an stupid Mario. That was uncalled for.

Its only that this little problem completely breaks my workflow that I've had since I first started using Imatch 11 years ago, and now I dont know what to do. I dont really care if its Imatch or windows thats the problem, as long as I find a solution. I tried searching the user manual and forums for information first, and when I didnt find an answer there, the only place I can go is here. How am I supposed to know if its Imatch or Windows thats the problem without asking first?

[Mario]

I just tried to give you a solution since I'm not sure what I could do else.
If you have no MS support contract you may be successful by asking in one of their free forums.
Maybe they did change how Windows Explorer deals with Metadata in the Fall Creators Update. I don't know.

If seeing this data in Windows Explorer is paramount to your workflow, we first need to know where Windows Explorer gets the data from.
As my test shows, it apparently prefers EXIF data. But uses created when XMP is in the file and digitized (or vice versa) when EXIF and XMP is in the file..
Have you tried all of the various Date columns you can activate in Windows Explorer? If you use the "More..." option you'll see many date Attributes, including created, but also things like acquired, ...

[Jingo]

Not sure if it is an option for you.. but I've using a windows explorer replacement (XYplorer) for many years... it allows you to choose what columns to display and you can define custom columns definitions... might help you out!

[muggost]

Not sure if it is an option for you.. but I've using a windows explorer replacement (XYplorer) for many years... it allows you to choose what columns to display and you can define custom columns definitions... might help you out!

Thanks for the tip, I'll check it out!

If seeing this data in Windows Explorer is paramount to your workflow, we first need to know where Windows Explorer gets the data from.
As my test shows, it apparently prefers EXIF data. But uses created when XMP is in the file and digitized (or vice versa) when EXIF and XMP is in the file..
Have you tried all of the various Date columns you can activate in Windows Explorer? If you use the "More..." option you'll see many date Attributes, including created, but also things like acquired, ...

Yeah, I tried all the other Date columns and they dont show the same fields as in Imatch, so something has definitely changed. Windows explorer really is a rotten piece of software and I'm very disappointed now. I've been scanning old photos from late 1890s and early 1920s and using Imatch to re-date them all. They all show up nicely in Imatch of course, the problem occurs is when I want to export or send them to someone else. Like google photos or just by email/dropbox to someone else. They want to see the date (or at least the year) the picture is taken.

I need to find a workaround, and for now the best option seems to use "Date Digitized" in Imatch to set the system file date, and then manually set "Date Created" on all pictures to get the Imatch date correctly. Unless I can find some other way to make Imatch force update the file's Date Taken field while simultaneously updating the corresponding Imatch field.

[Erik]

Not sure if it is an option for you.. but I've using a windows explorer replacement (XYplorer) for many years... it allows you to choose what columns to display and you can define custom columns definitions... might help you out!

Thanks for the tip, I'll check it out!

If seeing this data in Windows Explorer is paramount to your workflow, we first need to know where Windows Explorer gets the data from.
As my test shows, it apparently prefers EXIF data. But uses created when XMP is in the file and digitized (or vice versa) when EXIF and XMP is in the file..
Have you tried all of the various Date columns you can activate in Windows Explorer? If you use the "More..." option you'll see many date Attributes, including created, but also things like acquired, ...

Yeah, I tried all the other Date columns and they dont show the same fields as in Imatch, so something has definitely changed. Windows explorer really is a rotten piece of software and I'm very disappointed now. I've been scanning old photos from late 1890s and early 1920s and using Imatch to re-date them all. They all show up nicely in Imatch of course, the problem occurs is when I want to export or send them to someone else. Like google photos or just by email/dropbox to someone else. They want to see the date (or at least the year) the picture is taken.

I need to find a workaround, and for now the best option seems to use "Date Digitized" in Imatch to set the system file date, and then manually set "Date Created" on all pictures to get the Imatch date correctly. Unless I can find some other way to make Imatch force update the file's Date Taken field while simultaneously updating the corresponding Imatch field.

A potential solution is to make sure there can be no problems.  I share files and work in the files system regularly where people are using Explorer.  My solution to making the date I want available to everyone and consistently was in how I name the file itself.  All my image files' names begin with the date the photo was shot (e.g. Date Taken).  i.e. If I have a file taken today, it's file name would be 20180103****** (2018, January, 03). 

Now if I go into the file system and sort by file name, the files are sorted chronologically.  I don't need to worry about what Explorer interprets as the date.  Of course if sorting isn't an issue you could put the date anywhere in any format.

Of course, if you have a file naming scheme that is fixed and doesn't involve dates (or can't out of other need) then this wouldn't work for you. 

By the way, I also second the XYplorer suggestion.  It was worth the price (they may have had a free version, but I paid for a license).  But, when it comes to sharing you have to cater to the lowest common denominator, which is Explorer.

[Mario]

I need to find a workaround, and for now the best option seems to use "Date Digitized" in Imatch to set the system file date, and then manually set "Date Created" on all pictures to get the Imatch date correctly. Unless I can find some other way to make Imatch force update the file's Date Taken field while simultaneously updating the corresponding Imatch field.

I don't understand...

There are basically two timestamps in EXIF and XMP: "Digitized" and "Created".
For images taken with digital cameras, both timestamps are usually identical. For digital images created from scans, the "digitized" date is usually set to the date and time when the scan was produced, and the "created" date is set to the date and time the original image was created (with an analog camera, for example).
IMatch can set both timestamps and we checked to make sure that they are set correctly. And also in synchronized across XMP and EXIF metadata.
IMatch cannot do "more".

The only problem seems to be Windows Explorer, which apparently favors one of the dates and does not allow you to show the other. Is this the problem?
That Windows Explorer does not really handle metadata well is a known fact. It depends on the Windows version and other factors whether or not it is good for anything. It's basically a tool to copy files around, and that's all it should be used for. For everything else, use a DAM 

[jch2103]

I'm travelling, so can't confirm via my desktop computer (that contains my scanned images), but a quick test on my laptop of assigning the "Created" EXIF/XMP timestamp to a file seems to show Windows Explorer displaying the correct file date (i.e, the same as the IMatch "Created" date). I don't however, use the 'extra' Windows Explorer dates, so it's possible something there has changed and I didn't notice. The Windows Explorer "Date Taken" field seems to correspond to both the Windows file date and the "Created" EXIF/XMP timestamp. See attached screenshots from IMatch and Windows Explorer.

I'm running the latest version of Windows 10 Pro.

[muggost]

For digital images created from scans, the "digitized" date is usually set to the date and time when the scan was produced, and the "created" date is set to the date and time the original image was created (with an analog camera, for example).

Yeah, that's what I'm used to, and the "Date Taken" in windows explorer was correctly updated to the date/time when the original picture was taken when I edited that field in Imatch. It's been like this for years and I cant understand why this has been changed. I've tested now with a previous version of Imatch which I havent updated on my laptop, and the same problem exists there. I'm betting the Windows Fall Creators Update has changed this. If I want the "Date Taken" field to be updated in windows explorer, I've either have to do it manually, or use the "Date Digitized" field in Imatch to do it.

Are you completely sure that something hasn't changed in Imatch that writes the metadata to another field in the image file than it used to do? (I have to ask you know, before I start with countermeasures to work around the problem....)

[Mario]

Nothing has changed. And you can review the data written by IMatch yourself, or look again at my analysis above.
Maybe somebody at Microsoft decided to use "digitized" instead of "created" for some reason. Only Microsoft can tell...

[muggost]

The final evidence:

I repeated the whole process: scanning a photo, importing to imatch, changing date taken, observering that the corresponding fields doesnt update in explorer, then uploading the photo to google photos. In google photos, the date is shown correctly (1990) so this proves Imatch is correct and windows explorer is wrong. I should have done this before "filing" my complaint here, cause this thread belongs in the windows forums instead.

Sorry for momentarily loosing faith in Imatch, it proves yet again to be the best digital asset management software around. Thanks for helping me out though - it is much appreciated

[Mario]

No worries. This community is for asking questions.

Frankly, Windows Explorer and how it handles metadata was always puzzling. And it changes between Windows versions. And now, apparently, even with the bigger updates.
If Explorer would offer columns named "Date Created" and "Date Digitized" and "File Created" and "File Modified" all would be well...

[Jingo]

I gave up on Explorer about 15 years ago... always ponying up for an explorer replacement... used Directory Opus for many years... but then switched over to the "lighter" XYPlorer and haven't looked back.  Why MS hasn't added in many of the standard "no brainer" items like split panels, advanced copy/paste/rename, etc is beyond me.  Whenever I use a work computer that doesn't have XYPlorer installed... I scratch my head at some of the bonehead thinking at MS... MAC OS is not much better with their FINDER application.... pretty basic and I had a FINDER replacement on that platform as well.

Highly recommend these explorer replacements... completes the system IMO.

[muggost]

This reminds me of another issue I had some 25 years ago with MS DOS 6.1. Anyone remember Norton Commander? The 90s version of XYPlorer...

Even properties/details on the file shows wrong date (attachment)