"force" vs. "favor" in Metadata 2

[lbo]

Hi Mario,

the difference between "force" and "favor" in Metadata 2 -> File Format Metadata Options could made clearer in the help.

Currently, the help states:

• Force XMP sidecar file: This option forces IMatch to use a sidecar file.
• Favor XMP sidecar file: IMatch uses an existing XMP sidecar file if it exists; else the Default settings are applied.

So one could guess that "Force" ignores embedded metadata, even if no sidecar exists, but IMO is not entirely clear from the current wording.

Just my 0.02EUR

Oliver

[Mario]

In force mode, IMatch overrides embedded metadata on a per-tag basis with data from the sidecar. If no sidecar exists, this of course does not happen.

[lbo]

In force mode, IMatch overrides embedded metadata on a per-tag basis with data from the sidecar. If no sidecar exists, this of course does not happen.

now I understand less than before.

Isn't the same true with "favor"?

[Mario]

It was years ago that I wrote that code. I don't recall the details anymore from the top of my head...
The favor causes IM to use sidecar if it exists, else embed XMP data.
Force can be used to override the embedding XMP data configured in the configuration for metadata.

Both options only exist only for specific purposes, to handle problem cases for commercial clients and migration projects. Normal users should never change these values.

[lbo]

It was years ago that I wrote that code. I don't recall the details anymore from the top of my head...

That's why unambiguous documentation is so important.

The favor causes IM to use sidecar if it exists, else embed XMP data.
Force can be used to override the embedding XMP data configured in the configuration for metadata.

That's still not clear to me. Let me phrase simple questions:

What happens if no XMP sidecar file exists yet:

• Will "Favor" read image data and create a XMP sidecar file from the metadata embedded in the image?
• Will "Force" read image data and create a XMP sidecar file from the metadata embedded in the image?

In which way does "Favor" influence writing metadata to the image files?

In which way does "Force" influence writing metadata to the image files?

[sinus]

It was years ago that I wrote that code. I don't recall the details anymore from the top of my head...

That's why unambiguous documentation is so important.

If all the documentation on software products were as detailed as Mario's and IMatch's, then I'd be happy - and many other people would, too.

[Mario]

Each help page has a feedback link at the bottom.
If you have found an error or problem in the documentation, please use the official way to report it.
Click the link to send an email to one of my special post boxes. The email automatically contains the link to the help topic, which is a big help. The IMatch documentation has hundreds of pages.
I can then schedule time to look into it and fix problems or add more text or details.

Don#t expect me to have answers ready for all IMatch features and options from the top of my head.
I don't recall details of features and options implemented years ago and then never changed because they just work. IMatch is just too big.

In general, if something works for so many years without users discussing it, asking questions about it or reporting bugs, it just means that is is OK as it is or that users don't bother.
These options are not designed for you or normal users. They exist to be temporarily enabled to deal with specific metadata problems found during migration projects. Then they are set back to the defaults. No normal users should ever change these settings.

Overriding the normal storage schema for metadata (e.g. forcing XMP in sidecars for JPEG files) can be achieved by this. But this should be done only under controlled conditions, to handle specific problems. These features are for me to support my project work and for commercial clients which have to deal with metadata written over 20 years and 10 different software workflows. To consolidate, migrate and then switch all settings back to the standards.

[sinus]

To be honest, this whole "Metadata-Exif-iptc-sidecar..." or whatever is a big mess.
Thanks to camera manufacturers who do not adhere to standards or make their own soup, thanks to software manufacturers who also do not adhere to standards or/and create their own, thanks to Adobe, for example, who sometimes organised chaos, and last but not least thanks to standard manufacturers who also published contradictions among themselves or within their own association.

Regarding Adobe, they have done a lot of good in terms of standards and other things in the digital world, so I don't think this company is so bad.

We've had problems with metadata here on the forum in the past. I myself have had problems.
Since all this is so complicated and even more difficult for me as a non-English-speaking person to understand, I got into the habit of using a recipe that was simple for me:

When I have a problem, I make different copies and handle them differently in IMatch. Then I examine the results very carefully and (mostly) find a solution for myself at the end, even if such a test series sometimes takes a really long time. And if I found a solution and I have not more problems, I do not more touch this stuff. 

Of course I also look for solutions in the IMatch Help, but as I said, sometimes it still remains difficult for me to understand everything.
And of course also, here on this forum I have been helped very often!

As far as the problem here is concerned, it's something I honestly don't understand exactly because I simply took the default settings and never had any problems.
I even at first found not the fields, what lbo talked about.

I hope you can find a solution for your problem, Oliver!

Grrr ...Metadata crap ... I've had that so often and I'm glad when I don't have to touch it anymore.

[lbo]

If you have found an error or problem in the documentation, please use the official way to report it.

please excuse me for misinterpreting the intention of this board. I likely will use the feedback option of the help system after some more thinking and/or experiments.

Don#t expect me to have answers ready for all IMatch features and options from the top of my head.

I didn't expect this. On the contrary, I prefer a well-considered answer.

In general, if something works for so many years without users discussing it, asking questions about it or reporting bugs, it just means that is is OK as it is or that users don't bother.
These options are not designed for you or normal users.

You yourself have considered changing these defaults three months ago:

https://www.photools.com/community/index.php?topic=8630.msg60894#msg60894 (BTW: Two regulars supported your idea).

I'm still not able to foresee the full consequences because I don't understand the help.

[Mario]

As I said, force/favor should never been changed unless you want to break XMP compatibility with other applications.

Why would you even consider this? Which particular problem are you trying to solve by changing these standard settings?`
XMP data for RAW files goes into the sidecar, and for JPEG/TIF/PNG/PSD/DNG... it does into the file. That's industry standard, ensures optimal interop and works well.

IMatch allows customers to change that to solve very specific problems. 99% of all users never need this and maybe this is also one of the reasons why I deliberately kept the docs a bit fuzzy many years ago when I wrote this. And I plan keep them that way.

[lbo]

for your convenience, I quote part of your old posting I mentioned before:

But I wonder if I should switch IMatch to default to "favor sidecar / ignore embedded" for RAW files in the next version.

So you yourself considered changing the default settings for a reason, didn't you?

As I wrote, Jingo and jch2103 supported your idea.

As I said, force/favor should never been changed unless you want to break XMP compatibility with other applications.

Come on, you didn't want to break XMP compatibility three months ago by changing this setting, so why should it now?

Why would you even consider this? Which particular problem are you trying to solve by changing these standard settings?`

I want to avoid data duplication. "There shall be exactly one source of metadata."

Trying to sync between "XMP embedded in RAW" and "XMP in sidecar" opens a can of worms.
IMatch users have "been there, seen that".

For sure you know that in computer science, data duplication is mostly considered "A Bad Thing" (unless you have good reasons).

Unfortunately, you are nipping in the bud any approach to constructive discussion.

Vague warnings like "will break XMP compatibility" or "causes a massive amount of problems" are as unhelpful as "users don't need it" and maintaining to have "explained all this here in the community" without references. And "works for so many years without users discussing it" is not exactly what I observe in the few months participating in this forum.

I understand that you "don't recall the details years after writing the code", but exactly this should justify to re-think old decisions and document the new findings to make the knowledge available to all users.

So far the answer to your question what I want to achieve. Further discussing the right way of writing metadata in this thread would be off-topic, though. Please remember that all I asked here was the effect of "force" and "favour", and you fobbed me off that this setting wasn't meant for me and I shouldn't dare to question it.

maybe this is also one of the reasons why I deliberately kept the docs a bit fuzzy many years ago when I wrote this.

maybe.

Oliver

[Mario]

Sorry, I don't get your point.

I would never consider breaking XMP compatibility, I was just pondering options to deal with RAW files containing partial embedded XMP records, and explained the user how to solve this.

Again, what is your question about keywords? What problems do you need to solve?
If you cannot tell us the problem, we cannot help you solving it.

I have explained why IMatch offers force and favor and that these are very special features to solve very special problems. I'm not sure how I can explain it better than I already did.

[lbo]

Again, what is your question about keywords?

I didn't mention keywords in this thread.

The questions this thread is about:

What happens if no XMP sidecar file exists yet:

• Will "Favor" read image data and create a XMP sidecar file from the metadata embedded in the image?
• Will "Force" read image data and create a XMP sidecar file from the metadata embedded in the image?

In which way does "Favor" influence writing metadata to the image files?

In which way does "Force" influence writing metadata to the image files?

To catch possible remaining uncertainties: What is the difference between force and favor?

I was just pondering options to deal with RAW files containing partial embedded XMP records, and explained the user how to solve this.

well, your posting was about changing the IMatch default settings, therefore not for the special case but all new users.

And I'm still convinced that your idea still has to be considered, but that belongs to another thread.

[Mario]

I will search the answers for your questions as soon as I have some time. Currently too busy, sorry. And I don't remember all these details anymore after so many years.
If I don't reply to this within a couple of weeks, please remind me again.

[lbo]

Hi Mario,

many thanks for checking this.

I'll send a reminder after one month or so.

Oliver

[lbo]

Mario,

your reply in another thread leads me to clarify my questions which should be answered by the docs (IMatch help):

What happens if no XMP sidecar file exists yet:

• Will "Favor" read image data and create a XMP sidecar file from the metadata embedded in the image?
• Will "Force" read image data and create a XMP sidecar file from the metadata embedded in the image?

What happens, if a a sidecar exists but contains not all tags the image contains:

• Will "Favor" read the tags from the image file that are missing in the sidecar?
• Will "Force" read the tags from the image file that are missing in the sidecar?

IOW does "force" and "favor" work on a "per tag" basis or on "all or nothing" basis?

In which way does "Favor" influence writing metadata to the image files?

In which way does "Force" influence writing metadata to the image files?

To catch possible remaining uncertainties: What is the difference between force and favor?

[lbo]

I will search the answers for your questions as soon as I have some time. Currently too busy, sorry. And I don't remember all these details anymore after so many years.
If I don't reply to this within a couple of weeks, please remind me again.

although it's a bit more than a "couple of weeks", I remind you as requested.

[Mario]

Maybe somewhen in IMatch 2020.
I have thought about this for there are so many things depending on this, from ingest to propagation. The current treatment works reliably and good for many years.

[lbo]

Maybe somewhen in IMatch 2020.
I have thought about this for there are so many things depending on this, from ingest to propagation. The current treatment works reliably and good for many years.

just to avoid misunderstandings: The posting dated 2019-04-09, 17:35:26 is about documenting the current behavior or Force and Favor, not changing IMatch.