XnView Software

I really like the new MP a lot! Thanks Pierre! There is only 1 biggest request, is a importer for previous 1000s of saved category.db info!! Without this, I can not migrate over! It will be nice to also build in a way to backup these critical info instead of just going to find those files to backup!

Sincerely,
Perry

Such a db time-saver tool is mentioned in topic, Database Migration utility.

Yes, I saw that post, it was 6months ago. Wondering any progress? In order for me to migrate over, I really don't want to spend another 48hrs trying to keywords them again. Any progress? BTW, as far as the speed, would it slow down the search?

Sincerely,
Perry

pc001 wrote:Yes, I saw that post, it was 6months ago. Wondering any progress? In order for me to migrate over, I really don't want to spend another 48hrs trying to keywords them again. Any progress? BTW, as far as the speed, would it slow down the search?

When the database format of XnViewMP will not change anymore, i'll make this tools...

Thanks Pierre. Just curious, so, then, all the data of a file is embeded within the file itself, right? So, when a file is moved from one machine to another, or when the machine crashes and I need to rebuild it, then, how do I backup the xnview db? Please explain how this process works? Thanks.

In Him,
Perry

pc001 wrote:Thanks Pierre. Just curious, so, then, all the data of a file is embeded within the file itself, right? So, when a file is moved from one machine to another, or when the machine crashes and I need to rebuild it, then, how do I backup the xnview db? Please explain how this process works? Thanks.

On XnView 1.97, rating, color label & cateogories are stored in the DB not the file. With xnViewMP, you can store it in the file (if the format support it)

Pierre, when you say "you can store it..." does that mean users can customize it? What are the pros and cons? Would saving to the file slows down the search? Can user choose to save to both? (BTW, I don't see where you customize this). My main concern is how to back up the DB if machine crash. If Keywords/metadata is saved to the files, I only have to backup the files. However, that may mean slower search? I obviously do not understand this well. Thanks Peirre, I really love your program!

Sincerely,
Perry

If you use DB, you can speed up search for example.
You can store rating/categories in DB & file (export settings in option/Metadata)

If the DB is lost you have just to reimport the files. That could take some time but it is easy.
Another advantage to store keywords also into files : you don't lost them even if you switch to another software* since it is stored in a standard way (IPTC/XMP). So, the best choise (IMHO) is to store metadata into DB & files.

*I know, nobody would do that

mahikeulbody wrote:So, the best choice (IMHO) is to store metadata into DB & files.

Yes. I agree, an ideal situation. Except...

The question arises of how and when to synchronize the two sets of data, and how to determine when synchronization is needed. Most of us use several tools in addition to XnView to either access or modify the image metadata.

Suppose the user changes metadata of a set of images using Lightroom, then returns to XnView to manage those image files (since XnView is superior to Lightroom for that purpose).

What should happen? Automatic synchronization? A message to the user? How would the synchronization activity affect responsiveness of the XnView GUI for concurrent activities? Checking for "new, unsynchronized metadata" in each image (or in the database but not in the image) could be very disk intensive, for instance.

Another issue: Some metadata might be considered intrinsic to the image itself (GPS location data, for instance, or copyright) and be intended to persevere with the image for the "life" of that image. Other metadata might be related to the process or project of which the image is a part (version info, or perhaps rating, or be unique to the tool used on the image), with no need to maintain the data forever.

This might suggest that only some fields need synchronizing at any particular time, not all.

My point is that "store metadata into DB & files" (no matter how desirable it sounds) could be more complicated than it first appears. In many cases user decisions and manual intervention in the synchronization activity will be needed.

I agree (store metadata into DB & files) can be complex to manage (possible data doubloons, other softs,...) and is unfortunately destructive, it's what why the best behavior for XnView, is to have a none destructive behavior (set by default) for the images themself of course, but also for all the embedded meta-datas. (Even if the photos/files are not write protected !)

...After that, an user customization must be also possible to allow the change of this default "none destructive behavior" ( for images and/or meta-datas), ...but with a Xnview warning.

Various ideas regarding handling of meta data can be read in topic IPTC/XMP for hierarchical categories + internal DB. I still think that meta data should be stored in the images themselves as written in my post http://newsgroup.xnview.com/viewtopic.p ... 058#p47058. XnView should read, write and cache this metadata for quick access and searches, but XnView should not be the "master" of the meta data. The image files themselves should store the meta data and hold the master meta data.

Synchronisation
Synchronizing meta data between cache and image files is something that has to be discussed and thoroughly designed. A possible way for synchonrisation:

When changing metadata, typically filesize or timestamp is changed, too. So XnView could keep both file size and timestamp in the cache and find out about changes by comparing filesize and timestamp in cache with the actual filesize and timestamp (for example). Additionally, an MD5 (?) checksum might be kept in the cache. The checksum could be used to find all changed files (more reliable than just file size and timestamp).

When changing in XnView, meta data will be in sync. For synchronising all other changes a periodical background job could be used and/or the user could trigger synchronisation (I prefer the latter).

That's just some ideas...