[BBD] Unwanted Invalid Categories

[JohnZeman]

For quite awhile now I have been trying to figure out what I do that causes IMatch (2025.2.4) to generate unwanted invalid new categories (See attached screenshot)

In this example the legitimate categories I have created and assigned are the 2 following.

@Keywords|Things|Homes away from Home

@Keywords|Things|Our Things|Machines|Vehicles|2011 Chevy Colorado

However IMatch occasionally generates versions of those categories (and other categories, I'm just showing these 2 in this thread) that look like this...

@Keywords|Machines
@Keywords|Our Things
@Keywords|ThingsHomes away from Home
@Keywords|ThingsOur ThingsMachinesVehicles2011 Chevy Colorado

It seems to happen when I reprocess existing photos in my database and then writeback metadata/propagate data to versions.

This has been going on for awhile, I don't recall it happening in IMatch 2023 though.

[Mario]

@Keywords is based on the actual keywords in your files.
Check the images in these "unwanted" categories and see which keywords they contain in the Keywords Panel.

A good source for troublesome keywords is legacy IPTC metadata or "flattening" options which, in conjunction with your thesaurus, produce the unwanted keywords when IMatch has to re-import an image.

There is no general rule or solution.
I would first run the Metadata Analyst on a file in an unwanted category so see if it finds issues.
Then I would look at the image in the ExifTool Command Processor with the "Keywords" preset to see which keywords are in the file.
And then go on from there.

[sinus]

I am not sure, but when you have a file with the keyword Machines, IMatch create a keyword in the categories with Machines. Looks normal to me.

They are Keywords, hence they were created, what does IMatch since a long time. Or do I get it wrong?

[Tveloso]

This sounds very similar to what was being discussed in this topic:

    Hierarchical Keywords Processing

Although there, when IMatch "broke up" a given hierarchical keyword into "smaller parts" (creating a new Keyword), the pipe delimiter was retained in the new Keyword, whereas in John's example here, it is sometimes stripped - and the  resulting keyword is a concatenation of the original (or parts thereof).

John, in one of your posts in that other topic, you mentioned that manually propagating, corrected that problem for you:

But then if I then select the 5 CR3 masters and do an F4,P to manually propagate metadata from masters to versions the problem goes away, the JPGs will then only have the correct

Things|Our Things|Garden Shed

Keyword assigned.

Might that still be the case?

I checked my @Keywords category for any instances of this issue, and did not find any...

[JohnZeman]

Many thanks to all who have responded, the mystery is solved now and you're right, the guilty culprit is not IMatch after all.

It's ON1 Photo Raw 2025, the raw processor I started using last November which is about the time I began seeing the problem.

In some images but not all, ON1 butchers the original keywords and then exports them to Affinity Photo which exports the final JPG version back to IMatch.  And now that I think about it more, all of the mangled invalid @Keyword categories were in JPG files.

So my solution is to disable keyword exporting from ON1 and to let IMatch handle the keywords, which I should have done in the first place.

Please archive this false bug report Mario and thanks again to all who have responded.

[Mario]

Good result. Glad to hear that you figured it out and fixed it.