No one is flamed or grilled here, John.
JohnFredC wrote:... Unless the tool in use respects the link between the centrally cached data and the image file under all circumstances of moving, copying, etc, then the best place for the cached data is with the image itself!!!
I like and support your general statement approach and also think that image
meta data must be embedded in each image. The crux here is that only few file formats support image meta data. And XnView is a file viewer for many image formats.
General basis for storing image meta data
Whenever possible, existing means should be used. In the case of storing image meta data like description, categorization, and so on, it is the IPTC data embedded in JPG files which is this means. Current limitation is that IPTC data can be stored in some few file formats like JPG, only.
For other file types, a more or less similar means for storing image meta data should be found. This solution might be a small file per file
containing an XML description of the image meta data which lies in every folder. So the user would be able to edit IPTC data for any image format or video file, be it bmp, gif, png, avi, ... In case of JPG it would be stored as part of the image, in case of other file formats which do not support IPTC it would be stored as XML description file. One general interface for image meta data for all file formats.
Requirements in Handling
Once the above basis for storing image meta data is there, it must be made sure that the following requirements can be fulfilled:
a - Ensuring that image and image meta data is always bundled together
b - Accessing this information quickly
c - Allowing for searching (quickly)
d - Possibility to move the images within the file system or onto another PC/medium without loosing the image meta data.
Decentral image meta data, but central database
Some mass actions would work with the image meta data in each single folders, but I think for performance reasons most of the mass actions like "show me all images in category 'x') for example wouldn't.
From my point of view the above requirements can be handled by a central database only. This central database can be native (whereas the image meta data should be XML and thus open to public and other programs).
For building up the central database there must be a way for reading
in decentralized image meta data into the centralized database, this means reading of folder and subfolders" on user demand. Reading on-access would not be sufficient, because one would have to browse all folders first and then one could search.
When copying and moving image files XnView must ensure that the image meta data is copied or moved, too.
That's some of my thoughs (quickly written up). Handling masses of images is an important area for image viewers. It would be good if a good solution could be found and implemented in XnView.
Note: From what I can remember there was once a related thread with posts from Olivier. Perhaps someone can find it...