Problem with Batch Processor

[maffe69]

Hi everyone!
I have a problem with iMatch 2018 and its batch processor. I export a picture in jpeg, setting the "metadata" options to "Always write metadata to output file" and "All metadata including EXIF Camera Info". The exported jpeg files contains the correct exif metadata, and in particular the "Create date" and "Date/Time Original". However, the XMP field "Date Subject Created" is set to the current date and time, and this seems to prevent iMatch from correctly report the date and time in the browser and sort according to capture time. Other browsers read the date and time of the resulting jpeg just fine. This happens with RAW files (Sony and Olympus) and jpeg source files.
Please, does anybody have a clue?
Thanks in advance for your help!
Best,
Marco

[Mario]

EXIF has never been designed to be copied between files. And when copying XMP, IMatch sets some of the tags according to the current situation, file format and date.
I recommend not to copy EXIF data from the original file to derivative files created with the Batch Processor. Most of the data will be wrong anyway.

[maffe69]

Let me further clarify the issue I'm facing: I would like to export some files in standard jpeg format, keeping the correct original capture time. This should allow me to browse the exported files in iMatch and sort them according to capture time. Apparently, what I'm currently able to get out of iMatch is a set of exported jpeg files that do not show - in iMatch itself - the correct capture time and are not correctly sorted in the browser. I was asking for help, because I didn't know whether this was due to a misunderstanding of mine or a bug. Mario's answer seems to suggest that this is due to my uniformed attempt of copying EXIF data across files, and that many of the options provided in the Metadata tab of the Batch Processor do by design transfer wrong data across files. Now, to the best of my knowledge, exporting a picture in jpeg while keeping a reasonable subset of the original EXIF data - in particular the capture time - and make the software that exported the files correctly read those metadata back is not exactly rocket science. In my own personal and direct experience, this feat can be flawlessly performed in the following tools: Lightroom, Photoshop, Affinity, digiKam, XnView, PhotoNinja, Photoline, ACDsee, PaintShop Pro, Photomatix, EasyHDR, Dxo Photolab, Silkypix, and possibly others I forgot about. It seems to me that the software industry found somehow a way to deal with this issue. Now, again, I think that being able to export jpegs from iMatch that display the correct original capture date and time in iMatch itself is a reasonable expectation. I'm currently unable to obtain this behavior in iMatch, most likely due to my own gross incompetence. Is there any one able to help me out there? Is there any fellow user able to confirm that I'm not the only one facing this issue? Did anybody find a combination of settings that allows to get the result I'm looking for?
Thanks in advance.
M

[Mario]

I'm not sure that I can follow your elaboration entirely.
I just tried this.

Used a NEF file taken in June and converted it with the Batch Processor to a JPEG file.
I used the option "EXIF Camera Info: All Data" in the Copy Metadata option.
The resulting file has the same Created/Digitized timestamp than the original (2018:06:19 12:31:11) and also all other EXIF data of the source file.
I verified this with ExifTool and even Windows Explorer, Ps and Lr. Because you mention these products in your post.
This is the expected result.

I did the same, this time copying XMP and EXIF.
The EXIF data is the same in the file as in the source. Also the XMP data is identical.
Note that the file had no pending XMP write-back, which means that the XMP and EXIF were synchronized properly.

If you get different results, provide us with your detailed Batch Processor settings and a sample image (with XMP sidecar file if used) that reproduces the problem.
Also include a description of the settings you use under Edit > Preferences > Metadata and Edit > Preferences > Metadata 2 if non standard.

[maffe69]

First of all, thanks for your efforts! Let me see if I can clarify even further.
You may recall that in my first post I wrote: "The exported jpeg files contains the correct exif metadata, and in particular the Create date and Date/Time Original." We now both agree that exif metadata is copied correctly. Very good.
In my first post I also stated that the problem was with iMatch not being able to "correctly report the date and time in the browser and sort according to capture time." Since a picture is worth a thousand words, please consider the attached specimen1 screenshot. You will see three pictures, an Olympus .orf RAW file, and two jpegs, test.jpg and test-1.jpg. The first jpeg, test.jpg, has been created with the Batch Processor, using the built-in preset "Export to JPEG 100% medium sharpen" and setting the metadata option to "EXIF camera info: all data". The second jpeg, test-1.jpg, has been created with the same preset, but with the metadata option "All metadata including EXIF Camera Info". Please note that iMatch's browser reports the wrong capture time for test.jpg and the wrong capture date and time for test_1.jpg. Specimen1 and specimen2 show that the correct exif date and time is actually present in both files. By the way, this difference between outcomes is per se fascinating.
As far as the metadata2 tab in preferences, I'm pretty sure I didn't touch anything, but I can't be certain, so please find specimen3 attached, with a screenshot of the settings.
Finally, please note that this is not specific to an individual .orf file, since I get the same result with jpeg, tiff, and arw source files.
I hope this post finally makes my elaborations understandable, because I'm running out of resources: I can't think of a clearer way of reporting the issue.
Thanks again.
M

[Mario]

Please insert a new line / paragraph now and then in your posts (press Enter). Writing everything into one huge block makes your posts hard to read and not many users will bother.
I'm working mobile on your post is two screen pages of solid text...

In my first post I also stated that the problem was with iMatch not being able to "correctly report the date and time in the browser and sort according to capture time."

IMatch sets the file date/time it uses from the EXIF data in the file as described here: https://www.photools.com/help/imatch/#tech_exifdate.htm

If the EXIF data is copied and no XMP data gets in the way (!) the resulting files should show the same created/digitized file stamps as the original files. In my test (see above) this was the case. Both in IMatch, ExifTool, Ps and Lr.

Please attach your sample files or upload them somewhere and show us a link.
We need to check what metadata is actually in the file.
Also include the original files you have used for the Batch Processor.

Also, just in case do a Shift+Ctrl+F5 on the files and force a reload of the metadata.
Do you use versioning with metadata propagation perhaps?

[maffe69]

Sorry for my bad formatting habits. I'll follow your suggestion.

Once again, my issue is not about exif date and time not being written to jpeg file. This seems to be correctly done. Other programs - Zoner for instance - read it properly. I already made the point in my first post. My issue is with iMatch's browser no reading the date and/or time correctly. Can we please converge on this?

Shift+Ctrl+F5 or even a full rescan of the folder do not change the situation.

I took versioning into account. In order to avoid undesirable interactions, I exported the test files naming them test.jpeg and test-1.jpg. This prevents them from being identified as versions. Or at least it should if versioning works as advertised.

I'm happy to send you a link to my files, but not on a public forum. If you provide a private email address, I'll happily comply.

Thanks,
M

[Mario]

We need sample images.
Please use the official contact address given on the photools.com web site: support email address
Please include a link to this topic in your email so I can associate it with the community.

Please allow for several days before I download the files or reply. I get between 40 and 60 emails per day and there is always a backlog.

[maffe69]

Ok, private message sent.
No problem with you timeline.
Thanks in advance for your efforts.
Best,
M

[maffe69]

Hi, any news about the issue described in this post?
Thanks
M

[Mario]

Still on my to-do list. Still several other customer issues to analyze before that, sorry.

[maffe69]

Hi, is there any hope to get this issue examined in the near future? Thanks again for your efforts.
M

[Mario]

I have not yet looked into this because it seems to be a pretty isolated issue (a problem happening only on your system). I was totally busy shipping IMatch 2019 and IMatch Anywhere 2019 and now I'm busy with the aftermath.

This is a lower priority bug and I will surely look into this for one of the next releases. As always, when I have fixed a bug, I'll close and move the bug report. When I need more info, I'll ask in the bug report. When I don't post anything, the bug is still open.