How to force all metadata write-back (not only for these marked as pending)

[Ahto]

Due to DPI issue with built-in batch converter I started to batch convert images with Photoshop only to discover that sizable part of collection files did not have metadata written back to original files. And these metadata changes are not pending. Metadata is present in iMatch database, but not written back to part of files (files are writable). Nothing changes when I invoke write-back manually, as the files are not marked for update.

How can I force my entire database to write all metadata back to files to be sure everything is there? I want to force update of thousands of files.

[Mario]

1. Please elaborate on "DPI issue" in Batch Processor. What kind of DPI could that be? DPI is usually only relevant in printing. Images have no DPI, just pixels.

2. IMatch sets files as pending as soon as some metadata is changed in IMatch. The pending state is reset when IMatch has written metadata.
If you want to write metadata again, change some metadata. For example, click on the pen of one tag in the Metadata Panel to mark it as "changed", even if it is not. Then save and this will set the file to pending.

[Arthur]

Images carry a dpi information. default in windows is 72, I think, WPF likes 96 dpi. It says how big a picture is rendered on the screen. It defines the relation between logical and physical pixels.

[Mario]

Images may have a DPI setting in the EXIF metadata record, to inform a processing application about the intended output size of the image.
If you have an 2000 x 2000 pixel image and you set the EXIF DPI to 100, an application may consider printing it at 20 inches. Or not.
If you have an 2000 x 2000 pixel image and you set the EXIF DPI to 300, an application may print it at 6.6 inches. Or not.

IMatch uses the DPI information in the EXIF when you show image dimensions in the file window and you use either the cm or inch unit.

The Batch Processor embeds the DPI setting (as resolution) and the resolution unit in the EXIF record of the generated image, if you enable writing EXIF data.

[Ahto]

1. Please elaborate on "DPI issue" in Batch Processor. What kind of DPI could that be? DPI is usually only relevant in printing. Images have no DPI, just pixels.

Say I have 2 images, one is 300DPI TIF and another is 600DPI TIF. I want to convert them to JPG in batch mode, just as is with no scaling. The result must be 300DPI JPG and 600DPI JPG. Your converter requires me to enter DPI manually, which means that if I enter 300 then the TIF which was 600DPI will be converted to JPG that has 300DPI resolution written to header, making it to appear 4x larger and not in 1:1 size when printed or placed in DTP software. Yes, pixels are the same but it is not in proper scale any more, to print in original size.
I'm just talking of most basic conversion -- without scaling, without overlays, without borders -- just convert from one format to another and keep existing image size and DPI.
For a typical photographer this is not an issue but for users/archives who scan digital documents, maintaining proper scaling to reproduce in original size is requirement.

If you want to write metadata again, change some metadata. For example, click on the pen of one tag in the Metadata Panel to mark it as "changed", even if it is not. Then save and this will set the file to pending.

That makes no sense on thousands of files, one by one, for ALL metadata fields separately for EACH file?

[Mario]

1. There is nothing like a 3000DPI TIFF file. Your TIFF file has only pixels. Whatever in the EXIF record is suggested as the output DPI has no relevance for the IMatch batch processor. If your TIFF file has 3000 pixels, you can output it at 800 pixels with 72 DPI, 150 DPI or 300 DPI. I don't see what the problem is you are trying to solve. You can enter 123 DPI in the Batch Processor if this is what you need. The Batch Processor is DPI-sensitive for some of it's settings, see the help for details. Changing the DPI will not change the number of pixels the Batch Processor outputs, of course.

2. The Metadata Panel in IMatch works with the all selected files. If you select 1,000 or 10,000 files and toggle the pen for a tag, all 1,000 or 10,000 files will be marked as "pending".
As I said, I have no idea under which conditions IMatch would consider a file with unwritten changes as "current". The "needs write-back" state is reset only after a successful write-back.

But I would be real careful to determine that there is really metadata in your database that is not in the file. Writing back so many files will take al long time. And if is not really needed, you should not do it.
There was never a related problem reported so you may be interpreting what you see wrongly...

[Arthur]

He said 300 DPI. And what he wants to achieve is that if there are two tiffs with dpi x and dpi y set in the exif data, the batch processing should produce two jpegs with dpi x and dpi y.  He does not want x and y to be replaced by z, which is a parameter of the export, as I understand it. He wants to have something like "as original" for dpi on export.

[Ahto]

He said 300 DPI. And what he wants to achieve is that if there are two tiffs with dpi x and dpi y set in the exif data, the batch processing should produce two jpegs with dpi x and dpi y.  He does not want x and y to be replaced by z, which is a parameter of the export, as I understand it. He wants to have something like "as original" for dpi on export.

Exactly! I understand the DPI concept very well. Seems Mario is not very familiar with desktop publishing, where DPI value is the most important thing about an image.

[Ahto]

I'll work around it by setting up custom sorting by Exif/ResolutionX tag, so I sort images by DPI. Then batch process 300 and 600DPI images separately, then I can manually set DPI for each batch in the converter.

Kudos for making the program so customizable I can sort by anything.

To improve the converter, option to use DPI from source images can be added. Perhaps falling back to user setting in case resolution is missing from source file. Then each output file can have same DPI as source file.

[Arthur]

And for the writeback problem, you can select the root folder of your export context, display files from whole subtree, select all of them, and click on the modified pen of the 3-10 metadata tags which could have ever been changed by you. These are mostly tags like subject, label, rating, creation date, hierarchicalSubject. Should not be that much.

[Ahto]

And for the writeback problem, you can select the root folder of your export context, display files from whole subtree, select all of them, and click on the modified pen of the 3-10 metadata tags which could have ever been changed by you. These are mostly tags like subject, label, rating, creation date, hierarchicalSubject. Should not be that much.

I have the latest version and I'm unable to do that for many files at once, it overwrites metadata for all selected files, not only marks existing data as modified. Here is what happens:

1) I select a folder in "Media & Folders" tree.
2) I focus a photo, it's metadata is displayed.
3) I press Ctrl+A to select all files in the folder.
4) In Metadata list, section "Core data", field like Title, Description etc display "(Multiple values)" as items with different values are selected.
5) I press pen icon for Title field to mark it as modified.
6) I click on another photo to focus it, that also propagates the "mark as modified" to all previously selected files.
7) But what happens -- the Title from previously selected photo, which was selected when I pressed pen icon, is now copied to all selected photos, overwriting all original titles. So all photos in the folder have the same title.

[Arthur]

I have tried it with two of my files. I can confirm, that pressing the pen on (Multiple Values) field "Title", resets the field content in all selected files to the one of the focused file. Looks like a bug to me.

This is even worse for graphical fields like rating. Pressing the pen there while multiple files are selected, removes the rating of all selected files. Ok this becomes critical.

[ubacher]

I would just assign a label to all files and then remove the label. (If you don't use labels)
Or assign a star and remove if you don't use stars.

Could it be that Imatch actually tried to write back to the files but did not succeed - because of protection.
Or could it be that Imatch wrote the metadata to an xmp file which your other application does not read/know about?
Try on one file you know to be a problem.

[Ahto]

I would just assign a label to all files and then remove the label. (If you don't use labels)
Or assign a star and remove if you don't use stars.

Assigning a star will only update rating tag in metadata and will not add missing title, description etc. as iMatch only updates/adds modified tags and changing rating will not trigger update of Title etc.

[Arthur]

Hopefully the pen issue for multi selection gets resolved, as this is the only way to get metadata out of IMatch a second time.

[loweskid]

I have tried it with two of my files. I can confirm, that pressing the pen on (Multiple Values) field "Title", resets the field content in all selected files to the one of the focused file. Looks like a bug to me.

I think there is some confusion here.  When you click on the pen icon in the metadata panel while there are multiple files selected then it will indeed write the content of the focused file to all of them, as you have described.  This is the correct behavior.  From the help file.....

Pen Icon [in the metadata panel]

This indicator shows if a tag has been modified, modified but not yet been written to the file or not modified.

You can also use the Pen icon to mark a field explicitly as modified to force a write-back of that field to the file. This is useful when you're editing multiple files at once to write the data you see in the tag to all files.


What you should do is select all the modified files then click on a pen icon on any of the thumbnails in the file window, or use the command.. 'Metadata Write-back... For selected files...' (Ctrl-Atl-S).

[Arthur]

What you should do is select all the modified files then click on a pen icon on any of the thumbnails in the file window, or use the command.. 'Metadata Write-back... For selected files...' (Ctrl-Atl-S).

This command works only, if the files are known to have pending metadata writeback. Otherwise IMatch does nothing. It is not the first time people have problems getting their data out of the data base, when IMatch think everything is written back.

Does someone know whether it is possible to write an app, where the user defines a set of metadata tags, presses a button and the app marks all the selected tags in all selected files as modified?

[Mario]

What you should do is select all the modified files then click on a pen icon on any of the thumbnails in the file window, or use the command.. 'Metadata Write-back... For selected files...' (Ctrl-Atl-S).

This command works only, if the files are known to have pending metadata writeback. Otherwise IMatch does nothing. It is not the first time people have problems getting their data out of the data base, when IMatch think everything is written back.

Where did you get that from? Can you show me reference?

Does someone know whether it is possible to write an app, where the user defines a set of metadata tags, presses a button and the app marks all the selected tags in all selected files as modified?

Can you please explain under which conditions IMatch resets the write-back state on your system without writing back the data? I have never heard about such a thing.
There is no command to mark a file as "needs write-back" without changing anything.
I suggest you add a keyword to all files. Then remove the keyword again. This leaves the metadata unmodified, but the write-back state should stick and you can let IMatch write back the files.

[Mario]

Exactly! I understand the DPI concept very well. Seems Mario is not very familiar with desktop publishing, where DPI value is the most important thing about an image.

I' quite versed in DP, actually. Worked with a few DTP programs, still do.

It us just that the Batch Processor does not care a bit about the DPI setting in your original image.
It does not need that info, it has no reason to use it, none of the measures in the batch processor depends on this etc.

The Batch Processor uses the original image, resizes it to whatever dimensions you specify, maybe adds some text or a border and then outputs the file.
If the original file has 5000 x 5000 or 1000 x 1000 pixel is important, but not if these pixels are specified as to be intended as 100 DPI or 300 DPI for whatever virtual output device.

Maybe you need Photoshop for your specific workflow, but there is definitely no "DPI problem" in the Batch Processor. That was all I wanted to know.

[Ahto]

2. The Metadata Panel in IMatch works with the all selected files. If you select 1,000 or 10,000 files and toggle the pen for a tag, all 1,000 or 10,000 files will be marked as "pending".

Did you read my report above that this will not work as described by you here? It marks as pending but also overwrites metadata of all selected files with focused file metadata.

It us just that the Batch Processor does not care a bit about the DPI setting in your original image.
It does not need that info, it has no reason to use it, none of the measures in the batch processor depends on this etc.
...
...but there is definitely no "DPI problem" in the Batch Processor. That was all I wanted to know.

Batch processor just ruins/overwrites my original DPI value in the metadata. It is not big deal to you, I agree. It is an issue to me. If you scan/digitize documents then if you don't know the original DPI the paper was digitized, you will not be able to print it later in original 1:1 size. Do you understand that?

[Mario]

Did you read my report above that this will not work as described by you here? It marks as pending but also overwrites metadata of all selected files with focused file metadata.

This is the intended behavior. This feature marks the selected tag as modified and transfers the data to all selected files. See the IMatch help for details or the corresponding video in the IMatch Learning Center.
Add a keyword and save. Remove a keyword an save. This does not change the contents of your files but triggers the write-back.

If you find a situation in which IMatch resets the pending write-back stage but does not write back the data, let us know via a bug report.
If you modify the files you have in your IMatch database in external applications, double-check your settings for metadata protection. Else you may lose changes done but not yet written under some circumstances after IMatch has re-imported the file updated elsewhere. See also Using Adobe Lightroom® and IMatch together for related info.

Batch processor just ruins/overwrites my original DPI value in the metadata.

Nope. It produces a new output file so it cannot ruin or overwrite anything. Unless you replace an existing file that is.

The Batch Processor does not use the virtual DPI some files contain in their EXIF record. It has no use for that info, it only cares for pixels.
If you for some reason need to produce image files which have a specific DPI setting, you can even do that in the Batch Processor.
But there is no copying of source DPI to output DPI if this is what you need.
I doubt that many users care for that, need that and it may even produce the wrong results.

I'd say, for your specific workflow, use Photoshop.

Feel free to add a feature request for a new option for the Batch Processor which copies the source DPI EXIF fields to the output file.

[Ahto]

The Batch Processor does not use the virtual DPI some files contain in their EXIF record. It has no use for that info, it only cares for pixels.

By using "virtual DPI" you marginalize the DPI value. While it may be "virtual" for digital cameras, files produced by scanners usually contain physical DPI value which is required to interpret the data in original size. But I understand that this is a marginal issue for you.

[Arthur]

I suggest you add a keyword to all files. Then remove the keyword again. This leaves the metadata unmodified, but the write-back state should stick and you can let IMatch write back the files.

If there are many images with broken ratings on disc, maybe in sidecar xmps, and IMatch database contains still the correct ratings. Let's do not care who broke the ratings on disc. If I add and remove a keyword to those files in IMatch and writeback the files. Will the ratings on the disc also be repaired? Or will my ratings in the database will be copied over by the wrong file ratings from files? How do I get the correct ratings from database to files?

Again, I don't care how the delta between database and files may occure. Ahto has the problem, so it can occure. Maybe by his fault. But in my opinion, it must be possible to write back a set of selected metadata tags a second time

[Mario]

The Batch Processor does not use the virtual DPI some files contain in their EXIF record. It has no use for that info, it only cares for pixels.

By using "virtual DPI" you marginalize the DPI value. While it may be "virtual" for digital cameras, files produced by scanners usually contain physical DPI value which is required to interpret the data in original size. But I understand that this is a marginal issue for you.

Why don't you use your scanners DPI in the Batch Processor, it will then output this DPI value into the EXIF of the output file.

[Mario]

If there are many images with broken ratings on disc, maybe in sidecar xmps, and IMatch database contains still the correct ratings. Let's do not care who broke the ratings on disc. If I add and remove a keyword to those files in IMatch and writeback the files. Will the ratings on the disc also be repaired? Or will my ratings in the database will be copied over by the wrong file ratings from files? How do I get the correct ratings from database to files?
Again, I don't care how the delta between database and files may occure. Ahto has the problem, so it can occure. Maybe by his fault. But in my opinion, it must be possible to write back a set of selected metadata tags a second time

I'm not sure I can follow. What is a "broken rating"? A missing rating? A wrong rating?
When you change the rating in IMatch and write-back, IMatch will write back the rating. Since a file can have only one XMP record, and the XMP record can have only on rating, this will "fix" the broken rating.
When IMatch writes back, it writes back all modified values. It does not produce a new metadata record or write all database contents. IMatch uses as difference approach. If you only modify the rating, IMatch will not write the title or description or anything - only the rating.

When you have to deal with such issues, double check all applications in your workflow. Identify the application which is the cause for the broken ratings and update it or replace it.

[Ahto]

Why don't you use your scanners DPI in the Batch Processor, it will then output this DPI value into the EXIF of the output file.

If a batch of files to be processed is mixed of 300DPI, 600DPI, 1200DPI images then batch processor will assign the same DPI value to all of output files. There is no way to have original DPI of source image to be written to the converted image. That is the issue I was talking about. If you need to do part work manually then it is not as automated as it could be.

[Mario]

That yet another, even more special problem. I recommend a feature request. Then we'll see how many other users are affected by this peculiar problem.
Note that the Batch Processor uses the DPI you enter for measurements and units. Hence it also copies that value into the output file. If it would use the unit of the original image, positioning and sizing elements would be different for every file. Or it would output a DPI value that was not used while creating the image - which is what I meant above when I said "could be wrong".

Again, file a feature request and we can look into this for a later version if more than one user needs this.

[Ahto]

It is the same "DPI issue" I describe all the time here in this topic. Perhaps you finally understood about what I was talking. I need to improve my describing skills.

[Mario]

That's what I've explaind above. It's not an issue. It is just so that the Batch Processor does not behave as you would like it to. I think the current behavior is correct and as documented.
Feel free do add a FR.

[Ahto]

Seems the batch converter saga continues. If you enter 4-digit DPI value like 1200 or 2400 to converter, it seemingly accepts that but converted files show DPI of 999 in header. The next time converter window is opened, entered DPI value has reverted to 999.

[Mario]

Yes, there is a limit of 999 for the DPI setting in the Batch Processor.