Versioning and propagating question

[Mees Dekker]

My workflow starts with taking pictures in RAW. Then rename, rate and edit these pictures and save them as jpg in the same folder. Jpg is both buddy (for easy renaming and moving) and version (for propagating metadata). Write back RAW files. Metadata are propagated correctly. All is fine.

When I then want to make some of the jpg smaller (in order to send them via e-mail) I use the batchprocessor. Smaller jpgs are saved in the same folder, with the same filename but (25%) included in the name. Filerelations are set up in a way that this new smaller file becomes another version (but not a buddy) of the RAW master. However some metadata are propagated, some are not.

Since some of the metadata are "on write" attributes, I should write back the RAW file. But I did not touch the original RAW file (the second version is created from the already existing jpg) so there is nothing to write back for the RAW file. 

Can this be the reason for the partly incorrect propagating? If I manually propagate (F4,P) a couple of times, all metadata are propagated correctly, but this should be an automatic process (as per the help).  Do I miss something here?

[Mario]

Metadata is propagated when the master is written back. IMatch first writes back the master, then tells ExifTool to copy the data requested by the user in the version rule from the master to the version.

I understand that you have a rule that makes the 20% file a version of the master.
You create the 25% file via the Batch Processor. After the file has been created, it becomes a version, so metadata should be propagated from the master to the 25% file.

What do you mean by "partly incorrect"? Is metadata missing? Which?
Did you look at the 25% version in the ExifTool Command Processor? Does it contain the correct data?
What happens if you select the version and press Shift+Ctrl+F5 > Reload Metadata?

[Mario]

I think this is a caused by a timing issue.

The Batch Processor creates the file. It notices that the file is created in a folder already contained in the database and enqueues a request to rescan the files in the background processing queue.
IMatch scans the files and adds them to the database. The Relation Manager notices that the file is a version and creates the required links in the database. Then it checks all masters to see if there are masters that propagate metadata. If such masters are found, metadata is propagated.

In my tests I noticed that the version created by the BP shows in IMatch, and when I look at the metadata of the file with the ExifTool Command Processor, the data has been successfully propagated by the Relation Manager. But the file has not been rescanned / metadata reloaded afterwards, which makes the newly added data not visible in IMatch.

When I do a Shift+Ctrl+F5 > Reload Metadata, the propagated data shows up for the 25% version.
Can you check & verify this, please?

Somehow along these parallel executing and complex operations, IMatch "forgets" to reload the metadata after the propagation has completed. I will look into this for the next regular update.

[Mario]

I have fixed this by doing a rescan of the version.

NOTE: When you do this, and the master is pending write-back, creating a new version will not cause the master to be written back, the new version created by the BP will receive the data that is currently in the master file, not the data for the master only in the database, waiting for write-back!

A folder rescan which detects new files brings them into the database, but will never trigger other files to write back.
As soon as you write back the master, the version will be updated with the latest data. As usual.

[Mees Dekker]

Two tests:

• after editing and creating the jpg and not writing back the RAW file, I created the 25% file. Then wrote back all the files. "25%" files missed some metadata but after reloading, all the metadata were loaded.
• after editing and creating the jpg but writing back the RAW file and the jpfg file immediately (so no more pending write-back on neither the RAW nor the jpg), I created the 25% file. Even then the "25%" files missed some (not all) metadata but after reloading (with no write-back whatsoever), all the metadata were loaded and shown correctly.

I think you've nailed it. It is most likely a timing issue. 

Now that I know how to cope with this problem, I can live with it. But still I hope this can be solved in a future release.

[Mario]

This issue has been fixed for the upcoming 2025.5.2 release. See https://www.photools.com/release-notes/ for more information.

[Mees Dekker]

As always, top support that no other application I use can match.

[Mario]

As always, top support that no other application I use can match.

You're welcome. Let me know if you can still reproduce it.