Quick Filter problem with XMP/IPTC defect

Bugs which are supposed to be fixed in the next test version (not available yet)

Moderators: helmut, XnTriq, xnview, Dreamer

Post Reply
jkm
Posts: 67
Joined: Sat May 11, 2024 12:43 am

Quick Filter problem with XMP/IPTC defect

Post by jkm »

I'm encountering an obstacle and I'd appreciate it if anyone can suggest a workable way around it. There are some constraints, and XnViewMP doesn't seem to be updating some of its internal references as it should.

I need to update the metadata for several thousand image files. Because the information is beyond XnViewMP's capabilities, I will be using ExifTool in a script to access, update, and write the new information.

Here are the constraints:

1. The resulting metadata MUST be searchable by Quick Filter (Quick Search) in XnViewMP (I do not mean the advanced search Ctrl-F).
2. Quick Filter is incapable of searching XMP fields (even those XMP fields that have GUI elements. I find this hard to understand after so many years) and it will ONLY search IPTC fields.
3. I am writing the updated information to sidecar files to avoid touching the original image files
4. ExifTool does not write IPTC information to XMP sidecar files. Only XMP tags can be written to XMP sidecar files.

So right away, perhaps you can spot a problem: I have to get the information into IPTC for XnViewMP to be usable, but it's XMP only in the sidecar.

XnViewMP claims/seems to have some kind of syncronization between certain XMP and IPTC fields. As best as I can tell, this only partially works. Data appears to synchronize, but the IPTC is NOT immediately searchable.

In this example, I am using XMP:Instructions which maps to IPTC:SpecialInstructions

Here's how things play out, and they are the steps to reproduce what I think is a defect:

0. Metadata->Edit IPTC->Options->Mode: XMP, update or create IPTC-IIM
1. Place an XMP file next to a JPG file (x.jpg and x.jpg.xmp the example xmp file is shown at the end of the post)
2. Metadata->Update Catalog From Files
2b. Select in the browser the image that has the xmp file.
3. Metadata->Edit XMP (observe the data is visible in the Instructions field)
4. CANCEL Edit XMP
5. Metadata->Edit IPTC (observe the data is visible in the Special Instructions field)
6. CANCEL Edit IPTC
7. In Quick Filter, search for the data. (Type Visible)

You get no hits. The data is visible in the IPTC dialog, but it is NOT searchable.
It will not become searchable until you select a file, and do Metadata->Edit IPTC and WRITE.


So the data is properly imported. It's visible in XMP, and mapped and visible in IPTC, but it's not searchable. I think that's a defect. I think the IPTC version of the field should be searchable as soon as the data is imported if the options are set correctly, but it's not.

I have tried all four values of the Edit IPTC->Options->Mode setting, none resolve the problem.
Settings->Sidecar->Create or update XMP sidecar does not resolve the problem regardless of setting.

I'm aware I could write all the data into the subject or xmp:keywords, but I use subject for other things, and xmp:keywords is visible in the catalog filter and so is not appropriate. I am willing to use a field other than SpecialInstructions if it will work.

Not using sidecars and writing directly to the jpeg files also avoids the problem, but that's touching gigabytes of original files, so that approach is off the table for a variety of reasons.

Does anyone know a way around this? Individual actions for thousands of files is not a workable solution.

From an application standpoint, I think the best thing is for Quick Filter to finally search XMP fields.
IPTC is to a great degree deprecated in general use. XMP should be the priority. But this has been requested for years.

The second best thing is to fix the synchronization problem I demonstrated above so the IPTC data is immediately searchable.

But if someone can suggest a viable workaround I can use, I'd be glad to hear it...

Thanks...


x.jpg.XMP file below the ------ line

-------
<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 13.34'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>

<rdf:Description rdf:about=''
xmlns:photoshop='http://ns.adobe.com/photoshop/1.0/'>
<photoshop:Instructions>Visible in IPTC but not searchable
</photoshop:Instructions>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end='w'?>
jkm
Posts: 67
Joined: Sat May 11, 2024 12:43 am

Re: Quick Filter problem with XMP/IPTC defect

Post by jkm »

I just wanted to provide a quick update on this after a bit more testing. (Also, I received a notification that someone had replied, but the reply was not here when I checked the thread.)

The issue where XnViewMP won't search the IPTC data it has (and shows in the dialog) without writing the file I'll call the "Unsearchable Cached Data issue".

First, regarding using the "Write" (or Write All) button to nudge the app to make the metadata searchable.
Using the Write button in the Edit IPTC dialog isn't a suitable solution because this always writes the original image file, and not the sidecar. Since the whole point was to avoid modifying the original image file, this won't do.
Using the Write button in the Edit XMP dialog isn't a solution because using it does not make the IPTC data searchable.

So we seem to have a "Catch-22" or unwinnable situation:
  • The metadata that can be stored in the sidecar file without modifying the image file, XnViewMP won't search
  • The IPTC metadata XnViewMP has in its database, it won't search without modifying the image file
One of the main purposes of sidecar files (along with storing data the original image file can't hold, or for compatibility with other software) is to avoid modifying the original image file.

It looks like QuickFilter just can't search these sorts of fields without modifying the original image file, and that's a significant problem that somewhat hamstrings the whole sidecar file situation.

So it's full circle to where I was before. Fixing the Unsearchable Cached Data issue would certainly help, but the best thing would be to just make the XMP data searchable.

I would think fixing the Unsearchable Cached Data issue would be quick and straightforward; just do to the database whatever the Write button does without touching the image file.

Searching XMP would be more work, but would certainly yield much greater benefits for users. (IPTC is the past, XMP the future).

But one of these things needs to be addressed if QuickFilter is going to be functional for people who need to frequently search metadata or use sidecar files.
User avatar
xnview
Author of XnView
Posts: 46580
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Quick Filter problem with XMP/IPTC defect

Post by xnview »

The code is here but not activated, before XMP datas wasn't saved in database.
:bugconfirmed: Thanks to your detailed description I can reproduce the problem.
Pierre.
jkm
Posts: 67
Joined: Sat May 11, 2024 12:43 am

Re: Quick Filter problem with XMP/IPTC defect

Post by jkm »

Thanks for looking at it!

So the fix will allow data to be searched as soon as it is imported, without modifying the image file?
User avatar
xnview
Author of XnView
Posts: 46580
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Quick Filter problem with XMP/IPTC defect

Post by xnview »

jkm wrote: Mon Aug 25, 2025 5:57 pm So the fix will allow data to be searched as soon as it is imported, without modifying the image file?
yes no need to write IPTC datas
Pierre.
Post Reply