Meta data handling and Migration tool

Ideas for improvements and requests for new features in XnView MP

Moderators: XnTriq, xnview

Post Reply
pc001
Posts: 18
Joined: Wed Aug 12, 2009 11:27 am

Meta data handling and Migration tool

Post by pc001 »

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
marsh
XnThusiast
Posts: 2443
Joined: Sun May 15, 2005 6:31 am

Re: XnViewMP beta 0.26

Post by marsh »

Such a db time-saver tool is mentioned in topic, Database Migration utility.
pc001
Posts: 18
Joined: Wed Aug 12, 2009 11:27 am

Re: XnViewMP beta 0.26

Post by pc001 »

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
User avatar
xnview
Author of XnView
Posts: 34090
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: XnViewMP beta 0.26

Post by xnview »

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...
Pierre.
pc001
Posts: 18
Joined: Wed Aug 12, 2009 11:27 am

Re: XnViewMP beta 0.26

Post by pc001 »

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
User avatar
xnview
Author of XnView
Posts: 34090
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: XnViewMP beta 0.26

Post by xnview »

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.
pc001
Posts: 18
Joined: Wed Aug 12, 2009 11:27 am

Re: XnViewMP beta 0.26

Post by pc001 »

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
User avatar
xnview
Author of XnView
Posts: 34090
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: XnViewMP beta 0.26

Post by xnview »

If you use DB, you can speed up search for example.
You can store rating/categories in DB & file (export settings in option/Metadata)
Pierre.
mahikeulbody
Posts: 139
Joined: Sun Dec 13, 2009 4:54 pm

Re: XnViewMP beta 0.26

Post by mahikeulbody »

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 ;-)
User avatar
JohnFredC
XnThusiast
Posts: 2010
Joined: Wed Mar 17, 2004 8:33 pm
Location: Sarasota Florida

Re: XnViewMP beta 0.26

Post by JohnFredC »

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.
John
User avatar
oops66
XnThusiast
Posts: 1999
Joined: Tue Jul 17, 2007 1:17 am
Location: France

Re: XnViewMP beta 0.26

Post by oops66 »

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.
XnViewMP 0.82 Linux X64 - Ubuntu 16.04 LTS - X64
User avatar
helmut
Posts: 8219
Joined: Sun Oct 12, 2003 6:47 pm
Location: Frankfurt, Germany

Re: Meta data handling and Migration tool

Post by helmut »

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...
Post Reply