category re-import does not always happen.

[CameronD]

xnviewMP v0.78 x64 under windows 7.

Options Metadata -> IPTC & XMP under keywords are all ticked, with the aim that DB categories remain in sync with keyword metadata.

I view a jpg file in xnviewMP, exit, and add a word to IPTC:keyword & xmp-dc:subject.
The file modified date is updated and when xnviewMP returns to that folder it updates the keyword values it displays, updates the file's date in the xnview.db, but does not import the keywords to categories.
If I rename the file then it sees it as a new file and imports the DB categories as expected.

[jonha4711]

I've seen that as well. In fact, the interplay between DB categories on the one hand and XMP/IPTC entries on the other is unreliable in all directions. That's why I've decided to ignore XMP/IPTC and concentrate on categories. Alas, these can't be exported/imported easily from the database.

This part of XnViewMP could do with some reworking:-) Perhaps the next version...

[CameronD]

I've seen that as well. In fact, the interplay between DB categories on the one hand and XMP/IPTC entries on the other is unreliable in all directions. That's why I've decided to ignore XMP/IPTC and concentrate on categories....

I've taken the opposite tack.
I want my primary source of metadata to be retained within each image. I am then using xnview's category handling as a convenient way to access this.

[jonha4711]

I've seen that as well. In fact, the interplay between DB categories on the one hand and XMP/IPTC entries on the other is unreliable in all directions. That's why I've decided to ignore XMP/IPTC and concentrate on categories....

I've taken the opposite tack.
I want my primary source of metadata to be retained within each image. I am then using xnview's category handling as a convenient way to access this.

In an ideal world, I'd agree. If the transfer between database and XMP/IPTC were reliable, I'd see no reason not to have both. The main reason why I am sticking with XnViewMP database categories (at least for the time being) is SPEED: searching via the database is magnitudes faster than opening and searching through actual image files. If and when a future version has more stable XMP/IPTC handling, I certainly will batch-transfer my categories to the image files.

[CameronD]

Some IPTC and XMP data are also stored in the same DB, so there is no worry about needing to reread file headers, although the category handling is probably a bit more more efficient for searching.

My reasons are for reliability and portability - managing photos across multiple computers is possible, but if I rely only in the DB it is very easy for me to make mistakes leading to information loss.
There is also the possibility that one day I might start using Adobe Lightroom - xnview's use of XMP tries to be compatible.

[jonha4711]

Some IPTC and XMP data are also stored in the same DB, so there is no worry about needing to reread file headers, although the category handling is probably a bit more more efficient for searching.

Interesting. I did some tests and the speed difference when working with DB categories vs XMP/IPTC was enormous. The image files are on an SSD, the DB files on a ramdisk. Plus the XnViewMP search dialog is rather rudimentary... but YMMV.

There is also the possibility that one day I might start using Adobe Lightroom - xnview's use of XMP tries to be compatible.

Adobe software, along with any auto-updating stuff from Google (ie real programs, not online offers) and a couple of others, will alas never grace my machines. The "software" Adobe produces is in a league of its own. Again, YMMV : )

[CameronD]

...Interesting. I did some tests and the speed difference when working with DB categories vs XMP/IPTC was enormous. The image files are on an SSD, the DB files on a ramdisk. Plus the XnViewMP search dialog is rather rudimentary... but YMMV.

The search box has an option to "use catalog" or not. If you don't enable it then search will be slow, as you described.
If use catalog is ticked, then there should not be a great deal of difference in speed. The category search will be faster due to the way the different values are stored in the DB.

On a folder with 40k files, the category search with 71 matches was effectively instantaneous, while a keyword search took 3 or 4 seconds. Ah - that was searching on "IPTC:keyword contains".
If instead I search on "XMP:Subject contains" it takes minutes. And I think there is a memory allocation problem, so I'll start another bug report.

[jonha4711]

On a folder with 40k files, the category search with 71 matches was effectively instantaneous, while a keyword search took 3 or 4 seconds. Ah - that was searching on "IPTC:keyword contains".
If instead I search on "XMP:Subject contains" it takes minutes.

Well, that's it then: I have tested mainly with XMP because there the support for hierarchical categories seemed better. And to my untutored eye XMP looks to be a more "modern" standard anyway.

It would be a definite advantage if the metadata in the database (it's just an SQLite file) would not be a binary blob. For one thing, it would be possible to write a simple script that exports/imports part or all of the metadata. I'll put in a suggestion to that effect though I am not very hopeful as this would mean a complete refactoring of the database code.

[CameronD]

...It would be a definite advantage if the metadata in the database (it's just an SQLite file) would not be a binary blob.

Yes, it's a well-trodden path. This discussion is from nearly 3 years ago, and has not really happened yet.

[xnview]

my problem is if the user use DB only to store keywords, if the file is changed outside XnViewMP, metadata must be reloaded or not?
i agree in your case, that it's a problem if metadata is not reloaded...

what do you think?

[m.Th.]

my problem is if the user use DB only to store keywords, if the file is changed outside XnViewMP, metadata must be reloaded or not?
i agree in your case, that it's a problem if metadata is not reloaded...

what do you think?

The industry standard is that user must carry a decisive action (usually in a right-click menu, but not always) in order to update the metadata from XMP files.

We have this already in View | Update catalog from files and Update files from catalog (ok, perhaps in a right-click menu would be better) Also, a shortcut would be nice, for the ones who need to work extensively with this.

There is a (very) RARE, nice AND tricky addition tough, in some programs called „Automatic metadata sync” which does what it says based on Last Modified Date (LMD) of file (XMP sidecar or image file if the metadata is embedded there). However for this to work we need to have this date already saved in DB. WE DO HAVE this field already in DB but it isn't updated (why???). Also, be aware that normally we need two LMD fields: one for Image Data (pixels) and one for Metadata. I would suggest that for the time being to use only for Metadata.

Remember, that - as is - the metadata work in XnView MP is pretty fluid - in Lightroom for example you must pass a complete import in order to get the files in catalog and only after this phase you can (manually) update them etc.

WRT Metadata v2.0 (ie. breaking the Metadata Binary Blob in fields) - You have all my support. In fact the thread was started by me, isn't it?

[m.Th.]

I was asked about Lightroom way: Lr does NOT have an automatic update/sync.

However Lr scans the directory and for the files with changed metadata it shows an „Metadata changed externally” icon in the top-right corner of the thumbnail. See here:

Lr-way.JPG

If the user clicks on the icon, then another, very clear, dialog appears:

Lr-way-2.JPG

It supports, also, multi-selection.

So, it isn't automatic, but it is somewhat handy and very clear.

[CameronD]

I was asked about Lightroom way: Lr does NOT have an automatic update/sync.
However Lr scans the directory and for the files with changed metadata it shows an „Metadata changed externally” icon in the top-right corner of the thumbnail. See here:
...
If the user clicks on the icon, then another, very clear, dialog appears:
...
It supports, also, multi-selection.
So, it isn't automatic, but it is somewhat handy and very clear.

The LR process is not clear enough for me. I'll explain below.

To me, there are several possible responses, and they should ideally be a user-selectable option.

1. Always sync changes between file and database automatically
2. Detect changes/conflicts and indicate to user. This could be either:
   • notify via dialog box as soon as user selects folder with changed files, or
   • provide a visual hint as with the LR example
3. Ignore any changes (not sure whether this would ever be useful)

If the second option is taken then it is important that the user has a way to find out what changes will take place.
The LR dialog is typical of so many programs - we see something has changed, but we are not going to tell you what changed - quick, choose A or B!. There are many cases where I will know what has changed, but equally many when I have no memory of the changes, or a program has done something unexpected.